Using Kubernetes service accounts

A service account is a type of Kubernetes account that provides a distinct identity, in a Kubernetes cluster, so that you can allow or restrict access based on this service account. Application Pods, system components, and entities inside and outside the cluster can use a specific Service Account's credentials to identify as that Service Account. This is needed because the UID inside a K8s pod is not persistent, and changes frequently in OpenShift deployments. Therefore, access control based on user IDs is not feasible for such workloads.

Some service accounts may have administrator privileges to use any Kubernetes API resource on the cluster, while others may only have the privilege to start pods without any other access to the Kubernetes API.

Each service account is bound to a Kubernetes namespace. Every namespace gets a default ServiceAccount upon creation.

Configuring on CipherTrust Manager

Configure this feature on CipherTrust Manager. The feature uses the existing User Set. It leverages the unused UNAME value from the User Set, remapping it for use as a Service Account name. In your policy, you can add rules that allow or deny access to a CTE volume-based on the service account pod status.

• See Creating User Sets for more information.

Creating Namespace & ServiceAccounts in Kubernetes

1. Create a namespace, type:

   NS=<service-account-name>
   kubectl create ns "$NS"
   

   Example

   NS=<demo-sa>
   kubectl create ns "$NS"
   

2. Create service accounts, type:

   kubectl -n "$NS" create serviceaccount <service-account-role>
   

   Example

   kubectl -n "$NS" create serviceaccount sa-restricted
   kubectl -n "$NS" create serviceaccount sa-admin
   

   Note

   An sa-restricted service account cannot execute pods. Only an sa-admin service account can execute pods.

Restricted Role

The restricted role allows only the following functions on pods:

• get

• list

• watch

• create

Role-Based Access Control (RBAC) Examples

The following simple examples are provided so that you can use them to evaluate the feature. Use the service account feature in the appropriate method for solving your use case. Refer to the following Kubernetes documentation: Service Accounts, for more information.

Role: Restricted

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
    name: restricted
    namespace: demo-sa
    rules:
    - apiGroups: [""]
        resources: ["pods"]
        verbs: ["get","list","watch","create"]

Role: Administrator

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
    name: admin-lite
    namespace: demo-sa
    rules:
    - apiGroups: [""]
        resources: ["pods","pods/exec","configmaps"]
        verbs: ["*"]
    - apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["*"]

Role: K8s Restricted --> Service account restricted

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
    name: restricted-to-sa-restricted
    namespace: demo-sa
    subjects:
    - kind: ServiceAccount
        name: sa-restricted
        namespace: demo-sa
    roleRef:
    kind: Role
    name: restricted
    apiGroup: rbac.authorization.k8s.io

K8s Administrator --> Service Account Administrator

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
    name: admin-lite-to-sa-admin
    namespace: demo-sa
    subjects:
    - kind: ServiceAccount
        name: sa-admin
        namespace: demo-sa
    roleRef:
    kind: Role
    name: admin-lite
    apiGroup: rbac.authorization.k8s.io

• To apply it, type:

  kubectl apply -f rbac.yaml
  

Pod manifests

Demo of Service Account restricted yaml file

    apiVersion: v1
    kind: Pod
    metadata:
    name: demo
    namespace: demo-sa
    spec:
    serviceAccountName: sa-restricted
    volumes:
        - name: data
        persistentVolumeClaim:
            claimName: cte-clain
    containers:
        - name: app
        image: busybox:1.36
        command: ["sh","-c","sleep 365d"]
        volumeMounts:
            - name: data
            mountPath: /data

• To apply it, type:

  kubectl apply -f demo-pod-sa-restricted.yaml
  

Demo as Service Account Administrator yaml file

    apiVersion: v1
    kind: Pod
    metadata:
    name: demo
    namespace: demo-sa
    spec:
    serviceAccountName: sa-admin
    volumes:
        - name: data
        persistentVolumeClaim:
            claimName: cte-clain
    containers:
        - name: app
        image: busybox:1.36
        command: ["sh","-c","sleep 365d"]
        volumeMounts:
            - name: data
            mountPath: /data

• To apply it, type:

  kubectl apply -f demo-pod-sa-admin.yaml