A modern data marketplace that makes collaboration among diverse users (like business, analysts and engineers) easier, increasing efficiency and agility in data projects on AWS.
Add more restrictions to pivot role that DENY any updates on itself. This prevents the pivot role from granting more permissions to itself in case it is compromised.
As an alternative, the first thing that came to mind is the addition of permission boundaries: add the boundary to the pivot role would restrict the permissions that it can grant itself to the boundary specified. This solution does not restrict it to the absolute minimum level of permissions (which is what it currently has) unless we specify a permission boundary identical to the IAM role policy. Keeping a permission boundary in sync with the pivot role policies adds overhead.
Another alternative was to use NotResource in the IAM policy statements of the original IAM permissions; but it was not as intuitive. Plus, I like it better to specify the resources explicitly
Relates
Security
Security
Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.
Does this PR introduce or modify any input fields or queries - this includes
fetching data from storage outside the application (e.g. a database, an S3 bucket)?
Is the input sanitized?
What precautions are you taking before deserializing the data you consume?
Is injection prevented by parametrizing queries?
Have you ensured no eval or similar functions are used?
Does this PR introduce any functionality or component that requires authorization?
How have you ensured it respects the existing AuthN/AuthZ mechanisms?
Are you logging failed auth attempts?
Are you using or adding any cryptographic features?
Do you use a standard proven implementations?
Are the used keys controlled by the customer? Where are they stored?
Are you introducing any new policies/roles/users?
Have you used the least-privilege principle? How?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Feature or Bugfix
Detail
Add more restrictions to pivot role that DENY any updates on itself. This prevents the pivot role from granting more permissions to itself in case it is compromised.
As an alternative, the first thing that came to mind is the addition of permission boundaries: add the boundary to the pivot role would restrict the permissions that it can grant itself to the boundary specified. This solution does not restrict it to the absolute minimum level of permissions (which is what it currently has) unless we specify a permission boundary identical to the IAM role policy. Keeping a permission boundary in sync with the pivot role policies adds overhead.
Another alternative was to use NotResource in the IAM policy statements of the original IAM permissions; but it was not as intuitive. Plus, I like it better to specify the resources explicitly
Relates
Security
Please answer the questions below briefly where applicable, or write
N/A. Based on OWASP 10.evalor similar functions are used?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.