Topic outline

  • Security

    Kubernetes Security is a huge topic and security hardening is a nice problem which everyone has to implement according to their security requirements and the governance model of their organization. We're going only to scratch the surface of K8s security here and highly recommend to go through the following resources by Michael Hausenblas, Liz Rice and the community.

    • Service Accounts

      In K8s each namespace has a default ServiceAccount, named default. A ServiceAccount is a namespaced resource used by containers running in a Pod, to communicate with the API server of the Kubernetes cluster. ServiceAccounts with limited permissions are often used to apply the principle of least priviledge.

      k get sa --all-namespaces | grep default
      k get sa default -o yaml
      k get secret default-<press tab> -o yaml

      As you can see the data key of this Secret has several key/pairs, the token is the Base64 encoding of the JWT used to authenticate against the API server. Let's get the token and head to and use the debugger to decode the token.

      kubectl run -it alpine --restart=Never --image=alpine -- sh
      ls /var/run/secrets/
      cat /var/run/secrets/

      Paste the token and get the payload, which looks similar to this:

        "iss": "kubernetes/serviceaccount",
        "": "default",
        "": "default-token-24pbl",
        "": "default",
        "": "147e134a-43d0-4c76-ad01-bccc59f8acb9",
        "sub": "system:serviceaccount:default:default"

      We can see the service account default is linked to the namespace where it exists and is using the secret default-token-24pbl. This token is available in the filesystem of each container of the Pod of the attached ServiceAccount.

      Using a Custom ServiceAccount

      A Service Account on its own is on not so useful, we need to provide rome rights and permissions to it through a set of rules defined through roles or cluster roles using the RBAC implementation in K8s.