Kubernetes RBAC

Pain Point

Kubernetes includes a built-in role based access control (RBAC) mechanism that allows users to configure fine-grained and specific sets of permissions. This defines how users can interact with any Kubernetes object in the cluster, or in a specific namespace of the cluster. Developers need to manually create the roles, role bindings, and service accounts. Developers also need to configure RBAC for each Docker container by creating bindings between service accounts and roles. This is a manual and tedious process

The following YAML snippets demonstrate how to manually define a role, service account, and role binding for a single container

Complete Manifest files:

https://github.com/CloudplexPlatform/manifest-files/tree/master/kubernetes-manifest/rbac

role.yaml

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

role-binding.yaml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

service-account.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa
  namespace: default

Pod.yaml

...
Kind: Pod
...
spec:
   serviceaccount: users-sa
...

How CloudPlex addresses your pain

As shown below, in CloudPlex developers simply provide information about resources and permissions while CloudPlex automatically creates and configures the Service Accounts, Roles, and Role Bindings.