Kubernetes Role-Based Access Control (RBAC) Resource Considerations

The Kubernetes client attempts to GET/LIST/WATCH the following resources. It is highly recommended NOT to configure the admin key/cert or an admin service account.

The provided Kubernetes authentication credentials should have a minimum set of privileges to the following resources:

Essentially, you can create a special service account on your Kubernetes server with these minimal privileges. An example sequence of kubectl commands is below that will facilitate the creation of this serviceaccount. Note the use of the clusterrole (not role) and clusterrolebindings (not rolebindings) - these are cluster-wide roles and not per namespace. Using a role/rolebinding will not work as Secure Workload attempts to retrieve data from all namespaces.

$ kubectl create serviceaccount csw.read.only

Create the clusterrole.

A sample clusterrole.yaml with minimal privileges is provided below

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: csw.read.only
    rules:
      - apiGroups:
        - ""
        resources:
          - nodes
          - services
          - endpoints
          - namespaces
          - pods
          - replicationcontrollers
          - ingresses
        verbs:
          - get
          - list
          - watch
      - apiGroups:
        - extensions
        - networking.k8s.io
        resources:
          - ingresses
        verbs:
          - get
          - list
          - watch
      - apiGroups:
        - apps
        resources:
          - replicasets
          - deployments
          - statefulsets
          - daemonsets
        verbs:
          - get
          - list
          - watch
      - apiGroups:
        - batch
        resources:
          - jobs
          - cronjobs
        verbs:
          - get
          - list
          - watch

    $ kubectl create -f clusterrole.yaml

API groups for these different resources are susceptible to change across Kubernetes versions. The sample above should work for Kubernetes versions 1.20-1.24 and might require some tweaks for other versions.

Create the cluster role binding

$ kubectl create clusterrolebinding csw.read.only --clusterrole=csw.read.
˓→only --serviceaccount=default:csw.read.only

To retrieve the authtoken secret from the serviceaccount (used in the Auth Token field in the GUI) and decode from base64, you can retrieve the name of the secret by listing the serviceaccount with yaml output.

  $ kubectl get serviceaccount -o yaml csw.read.only
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: 2020-xx-xxT19:59:57Z
    name: csw.read.only
    namespace: default
    resourceVersion: "991"
    selfLink: /api/v1/namespaces/default/serviceaccounts/e2e.minimal
    uid: ce23da52-a11d-11ea-a990-525400d58002
  secrets:
  - name: csw.read.only-token-vmvmz

Listing the secret in yaml output mode will yield the token but in Base64 format (which is standard Kubernetes procedure for secret data). Secure Workload does not accept the token in this format, you must decode it from Base64.

  $ kubectl get secret -o yaml csw.read.only-token-vmvmz
  apiVersion: v1
  data:
    ca.crt: ...
    namespace: ZGVmYXVsdA==
    token: ZXlKaGJHY2lPaUpTVX....HRfZ2JwMVZR
  kind: Secret
  metadata:
    annotations:
      kubernetes.io/service-account.name: csw.read.only
      kubernetes.io/service-account.uid: ce23da52-a11d-11ea-a990-525400d58002
    creationTimestamp: 2020-05-28T19:59:57Z
    name: csw.read.only-token-vmvmz
    namespace: default
    resourceVersion: "990"
    selfLink: /api/v1/namespaces/default/secrets/csw.read.only-token-vmvmz
    uid: ce24f40c-a11d-11ea-a990-525400d58002
  type: kubernetes.io/service-account-token

To list the secret and output only the .data.token field and decode from base 64 encoding in one command, the following command that use the --template option is helpful.

  $ kubectl get secret csw.read.only-token-vmvmz --template "{{ .data.token }}" | base64 -d

This authtoken can be used for configuring a Kubernetes orchestrator in the Secure Workload UI instead of username/password or key/cert.

See EKS specific RBAC considerations.