Role Based Access Control

All clusters are configured with Role Based Access Control (RBAC). The authentication controller checks each API call with its attached role to allow or deny the call.

On this page you can find some generic documentation and examples on RBAC. Please make sure to consult the official documentation too.

Enabling RBAC

RBAC is enabled by default on each cluster.

Granting permissions

Each process or person making API calls must provide authentication (a token) and have permissions to make that call. You can grant permission by applying the Role, RoleBinding and optionally ServiceAccount objects to the cluster.

Cluster access for AWS IAM users and roles is configured through EKS access entries, set via spec.access.clusterAccessEntries in your cluster definition file. Each entry has:

• principalArn: the ARN of the IAM user or role.
• username (optional): the Kubernetes username the principal maps to; defaults to the IAM ARN.
• kubernetesGroups (optional): the Kubernetes groups the principal is a member of, which you can bind to Roles or ClusterRoles with (Cluster)RoleBindings.
• policies (optional): AWS-defined EKS access policies to associate with the principal, each with a name (for example AmazonEKSClusterAdminPolicy for full admin access) and an optional accessScope.

The AWS-defined policies are not editable, so for anything beyond the standard admin/edit/view permissions it is usually better to set kubernetesGroups and bind those groups to your own Roles with RoleBindings.

Custom Roles, ClusterRoles and their bindings are normally declared as code in the cluster’s custom-addons terragrunt stack (terraform/live/<environment>/eks/<cluster>/custom-addons/), with the Kubernetes provider: kubernetes_role_v1 and kubernetes_cluster_role_v1 for the permissions, kubernetes_role_binding_v1 and kubernetes_cluster_role_binding_v1 to bind them to a group or ServiceAccount. They are then version controlled and applied by the pipeline, together with the rest of the cluster configuration. Adding them to a chart, or applying a role.yaml by hand with kubectl apply -f role.yaml, also works, but those objects live outside your infrastructure code.

ServiceAccount

ServiceAccounts are special accounts for processes making API calls. These are not intended for human use.

You can specify which ServiceAccount to use in the Pod spec.

Roles and ClusterRoles

Sets of permissions are called Roles or ClusterRoles. The difference between the two is the scope. Roles are scoped to a Namespace, ClusterRoles apply to the full cluster.

There are also predefined Roles that Kubernetes provides by default.

Roles can be quite extensive. Be sure to check the official docs how to write them: https://kubernetes.io/docs/reference/access-authn-authz/rbac/.

(Cluster)RoleBinding

A RoleBinding is what binds a ServiceAccount or group to a Role.

Examples

Create a ServiceAccount, Role and RoleBinding:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: MyApp
  name: MyApp-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app: MyApp
  name: MyApp-role
rules:
  - apiGroups:
      - ""
    resources:
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app: MyApp
  name: MyApp-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: MyApp-role
subjects:
  - kind: ServiceAccount
    name: MyApp-account
    namespace: staging

Create a read-only RoleBinding for users from the foo GitHub organisation in the bar team:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: readonly-staging
  namespace: staging
rules:
  - apiGroups: [""] # "" indicates the core API group
    resources: ["pods", "pods/log"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: readonly-staging-binding
  namespace: staging
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: readonly-staging
subjects:
  - kind: Group
    name: foo:bar