You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be added:
I'd like to decouple the IAM roles' trust policy from kubernetes cluster details, while maintaining the service account level access controls.
There is no way to replace ABCDEFGHIJKL with * in this.
Removing it entirely allows any pod to assume the role.
It would be great if there was identical condition key like subject, that did not contain which IdP it was from.
Alternatively, it would be great to allow each EKS to set it's own subject prefix, so that we can target a subset of clusters that should have access (e.g. "production:subject": "system:serviceaccount:kube-system:my-service-account)
Why is this needed:
This is needed when we have many clusters and roles, some of which are ephemeral.
The text was updated successfully, but these errors were encountered:
What would you like to be added:
I'd like to decouple the IAM roles' trust policy from kubernetes cluster details, while maintaining the service account level access controls.
The condition looks like
There is no way to replace
ABCDEFGHIJKL
with*
in this.Removing it entirely allows any pod to assume the role.
It would be great if there was identical condition key like
subject
, that did not contain which IdP it was from.Alternatively, it would be great to allow each EKS to set it's own
subject
prefix, so that we can target a subset of clusters that should have access (e.g."production:subject": "system:serviceaccount:kube-system:my-service-account
)Why is this needed:
This is needed when we have many clusters and roles, some of which are ephemeral.
The text was updated successfully, but these errors were encountered: