-
Notifications
You must be signed in to change notification settings - Fork 536
Update SSO/Identity Center guidance for EKS access management #668
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Pratik! Overall very good content, just some minor comments.
Also, I believe we should merge with the existing content on Authentication and Authorization here, other than add a new subsection.
content/security/docs/cam.md
Outdated
|
||
## EKS access management options | ||
|
||
> ConfigMap-based access management is only supported in the short term, it will be deprecated soon and replaced by Cluster Access Management (CAM) API. For new EKS clusters, implement CAM API to manage cluster access. For existing clusters using aws-auth ConfigMap, migrate to using CAM API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aws-auth is already deprecated, just not removed yet. We can say it's deprecated but still supported in short term to match the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated wordings.
content/security/docs/cam.md
Outdated
#### Best practices: | ||
|
||
1. Use AWS Organizations to manage multiple accounts and apply service control policies (SCPs). | ||
2. Implement least privilege access by creating specific permission sets for different EKS role (e.g. admin, developer, read-only). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Least privilege principle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
content/security/docs/cam.md
Outdated
|
||
1. Use AWS Organizations to manage multiple accounts and apply service control policies (SCPs). | ||
2. Implement least privilege access by creating specific permission sets for different EKS role (e.g. admin, developer, read-only). | ||
3. Utilize attribute-based access control (ABAC) to dynamically assign permissions based on user attributes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ABAC is just supported on AWS based resources, not inside Kubernetes. We may need to highlight this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
|
||
#### Considerations/limitations: | ||
|
||
1. Role ARNs generated by Identity Center have random suffixes, making them challenging to use in static configurations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it's random prefixes, not suffixes. Can you confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's suffixes, confirmed.
content/security/docs/cam.md
Outdated
1. Role ARNs generated by Identity Center have random suffixes, making them challenging to use in static configurations. | ||
2. Limited support for fine-grained permissions at the Kubernetes resource level. Additional configuration is required for custom Kubernetes RBAC roles. Along with Kubernetes-native RBAC, consider using Kyverno for advanced permissions management in EKS clusters. | ||
|
||
### Option 2: AWS IAM Users/Roles mapped to Kubernetes RBAC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this are options related to CAM/Access Entries specifically, we may need to change to "...mapped to Kubernetes Groups". Since Access Policies are also based on RBAC, and the terminology may cause some confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed.
1. Scalability issues when managing large number of users or roles | ||
2. No built-in single sign-on capabilities | ||
|
||
### Option 3: OIDC Providers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we mention existing documentations about this, like this solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mentioned the doc.
@rodrigobersa @geoffcline Updated the IAM doc. Please take a look. |
Issue #, if available: #619
Description of changes:
Added guidance for EKS cluster API access from outside the cluster.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.