Authentication and Authorization
Click on the Authentication tab to drill down to the ServiceAccounts section and you can view Kubernetes service account resources by namespace.
Check out the Security module for additional examples.
A ServiceAccount provides an identity for processes that run in a Pod. When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace.
To view additional details for a specific service account, drill down to the namespace and click on the service account you want to view to see additional information such as labels, annotations, events. Below is the detail view for the catalog service account.
In EKS, you must be authenticated (logged in) before your request can be authorized (granted permission to access). Kubernetes expects attributes that are common to REST API requests. This means that EKS authorization works with AWS Identity and Access Management for access control.
In this lab, we'll view Kubernetes Role Based Access Control (RBAC) resources: Cluster Roles, Roles, ClusterRoleBindings and RoleBindings. RBAC is the process of providing restricted least privileged access to EKS clusters and its objects as per the IAM roles mapped to the EKS cluster users. Following diagram depicts how the access control flows when users or service accounts try to access the objects in EKS cluster through the Kubernetes client and API's.
Check out the Security module for additional examples.
A Role defines a set of permissions to be applied to a user. Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. A Role always sets permissions within a particular namespace, when you create a Role, you have to specify the namespace it belongs in.
Under Resource Type - Authorization section you can view ClusterRoles and Roles resources on your cluster listed by namespace.
Click on the cluster-autoscaler-aws-cluster-autoscaler role to view more details for that role. The below screenshot shows the cluster-autoscaler-aws-cluster-autoscaler role created under namespace kube-system which has authorization to delete, get, and update on configmaps resources.
A ClusterRoles are a set of rules that are scoped to a cluster and not a namespace, which makes them different from a Role. ClusterRoles are additive, and you cannot set "deny" rules. You would generally use ClusterRoles to define cluster-wide permissions.
A Role binding grants role permissions to a user or set of users. Rolebindings are assigned to a particular namespace during creation. The Rolebinding resource holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace like pods, replicasets, jobs, and deployments. Whereas a ClusterRoleBinding grants cluster scoped resources like nodes.
A ClusterRoleBinding attach ClusterRoles to a set of users. They are scoped to a cluster, and are not bound to namespaces like Roles and RoleBindings.
