Kubernetes includes a built-in role 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:
---- kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 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"]
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 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
apiVersion: v1 kind: ServiceAccount metadata: name: sa namespace: default
... 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.