Summary
In this chapter, we explored the basic concepts of authentication and authorization in native Kubernetes and how EKS differs. We described how EKS, by default, is integrated with AWS IAM and that a bearer code needs to be generated by a client tool such as kubectl in order for EKS to authenticate the user. This bearer code can be generated manually using the get-token CLI action or automatically using the kubeconfig file and will be submitted on every API request and be automatically validated by EKS.
We also described how the aws-auth ConfigMap is used by the Kubernetes RBAC sub-system to accept or deny any API request. It is important to place this file under version control and manage changes using a CI/CD pipeline as, by default, only the cluster creator has permission to do anything on the cluster.
Finally, we talked about how you can secure access to the API endpoints using IP whitelisting and/or security groups and how it is typically better to use private clusters...
