Closed gilbahat closed 2 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
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/kubernetes-sigs/aws-iam-authenticator/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