-
Notifications
You must be signed in to change notification settings - Fork 419
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
[Feature request]: support EC2 instance identities #696
Comments
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What would you like to be added?
EC2 instance identities (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-identity-roles.html) are unique ad-hoc IAM roles assigned to EC2 Instances. They are not currently supported by aws-iam-authenticator
Why is this needed?
opened to match pull request [https://github.com//pull/693]
First and foremost because they're there and support can be enabled. As implemented, aws-iam-authenticator throws an incorrect error.
I envision two possible use cases: cluster admission control and limited pre-access.
cluster admission control - in this scenario, a node candidate will be unable to connect as a node to the cluster until authorized by some other means (let's say an integrity check or security audit). A single IAM role shared by many nodes is unsuitable for this purpose, but ad-hoc identities are. The authorizing mechanism will add the relevant credentials to the auth-map once the node has been vetted.
limited pre-access. while candidate nodes are assumed to have system:nodes / system:bootstrapper privileges which are elevated, using them directly may be undesirable security-wise, for two reasons:
a. it may rightfully trigger a violation from monitoring tools
b. it entails using a superuser for what may be better served by a user with limited access
thus, using a scoped user for AWS identities may allow e.g. read-only access for data that might be useful by the node to configure/tune itself or other such customizations.
Anything else we need to know?
No response
The text was updated successfully, but these errors were encountered: