-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tighten IAM Permissions #33
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/lifecycle frozen |
/assign |
Assuming this means tagging resources on creation, and then limiting the cloud provider to modifying/deleting resources that are tagged -- the difficulty lies in upgrading to a version of the cloud provider that does this, and accounting for resources that were created prior to this feature being implemented. Possibly we can use a command line tool to look for resources by querying kubernetes APIs, i.e. looking at all the service objects to find load balancers to help with migration. This gets away from having to add permissions and complicated logic for a specific upgrade, but still has a pretty negative upgrade experience... |
Is it feasible to enable this improved security initially for clusters created after a flag date, and then document a mechanism to switch the cluster to the new security model? |
I too would like this. It should be simple if we follow @sftim's idea. |
Related to kubernetes-sigs/cluster-api-provider-aws#608
What would you like to be added:
Cluster API Provider AWS attempts to use least privileges whereever possible.
The project maintains a copy of the IAM policies used by cloud-provider-aws, but these are permissive compared to the use of IAM conditions in the Cluster API AWS.
If there is consistent tagging in use, then these permissions can be scoped down.
Why is this needed:
Enhanced security posture.
/kind feature
The text was updated successfully, but these errors were encountered: