Security on Kubernetes


A SecurityContext defines privilege and access control settings for Pods or
containers and can include the following:

  • UID- and GID-based Discretionary Access Control
  • SELinux security labels
  • Linux Capabilities
  • AppArmor
  • Seccomp
  • The AllowPrivilegeEscalation setting
  • The runAsNonRoot setting

Setting SecurityContext

  • kubectl apply -f security-context.yaml
  • kubectl get pod security-context-demo
  • kubectl exec -it security-context-demo -- sh
    • ps # will show processes running UID 1000
    • cd /data; ls -l # will show fsGroup as owning GID
    • id
    • exit


Kubernetes Users

  • The Kubernetes API doesn’t define users for people to authenticate and
  • Users are obtained externally
    • Defined by X.509 certificates
    • Obtained from external OpenID-based authentication (Google, AD and many more)
  • ServiceAccounts are used to authorize Pods to get access to specific API resources


Configuring Roles

  • Roles are used on Namespaces and use Verbs to specify access to specific
    resources in that Namespace
  • Use kubectl create role to create roles


Creating RoleBindings

  • RoleBindings connect users or ServiceAccounts to Roles
  • Use kubectl create rolebinding to create it


Creating ServiceAccounts

  • A ServiceAccount is used to authorize Pods to get information from the API
  • All Pods have a default ServiceAccount which provides minimal access
  • If more access is needed, specific ServiceAccounts can be created
  • ServiceAccounts don’t have specific configuration, they are used in RoleBindings to get access to specific Roles

Configuring ServiceAccounts

1. Create a Pod, using the standard ServiceAccount: kubectl apply -f

2. Use kubectl get pods mypod -o yaml to check current SA configuration

3. Access the Pod using kubectl exec -it mypod -- sh, try to list Pods using curl on the API:

1. apk add --update curl
2. curl https://kubernetes/api/v1 --insecure  # will be forbidden

4. Use the Default ServiceAccount token and try again:

1. TOKEN=$(cat /run/secrets/
2. curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/ --insecure

5. Try the same, but this time to list Pods – it will fail:

1. curl -H "Authorization: Bearer $TOKEN"https://kubernetes/api/v1/namespaces/default/pods/ --insecure

Configuring ServiceAccounts

1. Create a ServiceAccount: kubectl apply -f mysa.yaml

2. Define a role that allows to list all Pods in the default NameSpace: kubectl apply -f list-pods.yaml

3. Define a RoleBinding that binds the mysa to the Role just created: kubectl apply -f list-pods-mysa-binding.yaml

4. Create a Pod that uses the mysa SA to access this Role: kubectl apply -f mysapod.yaml

5. Access the Pod, use the mysa ServiceAccount token and try again:

1. apk add --update curl
2. TOKEN=$(cat /run/secrets/
3. curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/ --insecure

6. Try the same, but this time to list Pods:

1. curl -H "Authorization: Bearer $TOKEN"https://kubernetes/api/v1/namespaces/default/pods/ --insecure

We see above very simple mysa ServiceAccount definition and very simple role list-pods. This role is providing access to list pods.

The namespace of role binding is default. The subject is SA mysa and namespace default.



  • Roles have a Namespace scope, ClusterRoles apply to the entire cluster
  • The working is similar to the working of Roles
  • To provide access to ClusterRoles, use users or ServiceAccounts and provide access through a ClusterRoleBinding


User Accounts

  • Kubernetes has no User objects
  • User accounts consist of an authorized certificate that is completed with some authorization as defined in RBAC
  • To create a user account, the following steps need to be performed
    • Create a public/private key pair
    • Create a Certificate Signing Request
    • Sign the Certificate
    • Create a configuration file that uses these keys to access the K8s clust
    • Create an RBAC Role
    • Create an RBAC RoleBinding

Creating User Accounts

Step 1: Create a user working environment

    • kubectl create ns students
    • kubectl create ns staff
    • kubectl config get-contexts

Step 2: Create the User account

  • sudo useradd -m -G sudo -s /bin/bash anna
  • sudo passwd anna
  • su - anna
  • openssl genrsa -out anna.key 2048# Generating private key
  • openssl req -new -key anna.key -out anna.csr -subj "/CN=anna/O=k8s" # certificate signing request
  • sudo openssl x509 -req -in anna.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out anna.crt -days 1800 # kubernetes CA need to sign the signing request

Step 3: Update the Kubernetes Credentials Files for the new user

    • mkdir /home/anna/.kube
    • sudo cp -i /etc/kubernetes/admin.conf /home/anna/.kube/config
    • sudo chown -R anna:anna /home/anna/.kube
    • kubectl config set-credentials anna --client-certificate=/home/anna/anna.crt --client-key=/home/anna/anna.key

Step 4: Create a Default Context for the new user

    • kubectl config set-context anna-context --cluster=kubernetes \
      --namespace=staff --user=anna
    • kubectl config use-context anna-context # will set context permanently
    • kubectl get pods # will fail as no RBAC has been configured yet
    • kubectl config get-contexts

Step 5: Configure RBAC to define a staff role

    • su - student
    • vim staff-role.yaml
    • kubectl apply -f staff-role.yaml

Step 6: Bind a user to the new role

    • vim rolebind.yaml
    • kubectl apply -f rolebind.yaml

Step 7: Test it

    • su - anna; kubectl config view
    • kubectl create deployment nginx --image=nginx
    • kubectl get pods

Step 8: Create a View-only Role

    • su - student
    • vim students-role.yaml
    • vim rolebindstudents.yaml
    • kubectl apply -f students-role.yaml
    • kubectl apply -f rolebindstudents.yaml

Lab: Managing Security

  • Create a Role that allows for viewing of pods in the default namespace
  • Configure a RoleBinding that allows all authenticated users to use this role