new: Cluster Access Management API on Security

[rodrigobersa]

What this PR does / why we need it:

Walkthrough of using Cluster Access Management API replacing aws-auth to provide access to the cluster. The module covers;

• Understanding the API
• Managing Access
• Revoking Cluster Creator access
• Migrating aws-auth based identity mappings
• Creating granular access

Quality checks

• My content adheres to the style guidelines
• I ran make test module="<module>" it was successful (see https://github.com/aws-samples/eks-workshop-v2/blob/main/docs/automated_tests.md)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[netlify]

✅ Deploy Preview for eks-workshop ready!

Name	Link
🔨 Latest commit	77faef4
🔍 Latest deploy log	https://app.netlify.com/sites/eks-workshop/deploys/66579fc42e3c150008608c98
😎 Deploy Preview	https://deploy-preview-919--eks-workshop.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[niallthomson]

Hey @rodrigobersa ! I'm noticing quite a few of the pages have blank terminal sections showing like this:

https://deploy-preview-919--eks-workshop.netlify.app/docs/security/cluster-access-management/managing

To fix the pre-commit warnings you can either set up pre-commit or run this from the top level directory:

npx prettier -w .

It should modify a bunch of files.

[rodrigobersa]

Hey @niallthomson !

Yes, I created the whole content o Quip and ported to Git yesterday. I'll fix those issues today.

Also thanks for the tip for the pre-commit fix.

[niallthomson]

I'm concerned that the overall flow of this lab is based on some mistaken assumptions and the way we're modifying the cluster is a little risky.

For example, the content states that if you delete the cluster creator role then you don't have access to the cluster because it assumes CodeBuild creates the cluster, but in self-service mode this is not true.

I'd also prefer to avoid modifying/deleting the cluster creator role and its access. I think we should focus on just introducing new IAM roles (like EKSDevelopers) and adding access entries for these with different permissions.

Instead of using update-kubeconfig to overwrite the kubeconfig file every time I'd suggest we use something like:

aws eks update-kubeconfig --name $EKS_CLUSTER_NAME --role-arn arn:aws:iam::$AWS_ACCOUNT_ID:role/EKSDevelopers --alias developers --user-alias developers

kubectl --context developers get pod -A

This means that the original kubeconfig entries remain in place, which feels less risky to me.

Personally my suggested flow would be:

• Show how to provide cluster admin access to a new role called EKSAdmins. Do not interfere with the original cluster creator roles or access.
• Show how to provide read-only access to a new role called EKSReadOnly. This is basically the above but shows the limitations of the access provided.
• Show how to map a role to a Kubernetes group. Suggest using EKSDevelopers and creating a new Kubernetes RBAC group, rolebindings etc. Then demonstrate the very specific access that they have.