The kubernetes provides a Role based Access controls as a immediate mechanism as a security measure.
The roles are the grouping of PolicyRules and the capabilities and limitations within a namespace.
The Identities (or) Subjects are the users/ServiceAccounts which are assigned Roles which constitute a RBACs.
This process is acheived by referencing a role from RoleBinding to create RBACs.
In kubernetes there is Role and RoleBindings and the ClusterRole and ClusterRoleBinding.
There is no concept of a deny permission in the RBACs.
The Role and the Subject combined together defines a RoleBinding.
Now lets look at each of the terms in detail.
Subjects:
- user
- group
- serviceAccount
Resources:
- configmaps
- pods
- services
Verbs:
- create
- delete
- get
- list
- patch
- proxy
- update
- watch
You Create a kind:Role with a name and then binding with roleRef it to Subject by creating a kind: RoleBinding
[vamshi@master01 k8s]$ kubectl describe serviceaccounts builduser01 Name: builduser01 Namespace: default Labels: Annotations: Image pull secrets: Mountable secrets: builduser01-token-rmjsd Tokens: builduser01-token-rmjsd Events:
The role builduser-role has the permissions to all the resources to create, delete, get, list, patch, update and watch.
[vamshi@master01 k8s]$ kubectl describe role builduser-role
Name: builduser-role
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"builduser-role","namespace":"default"},"ru...
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
* [] [] [create delete get list patch update watch]
Using this you can limit the user access to your cluster
View the current clusterbindings on your kubernetes custer
[vamshi@master01 :~] kubectl get clusterrolebinding NAME AGE cluster-admin 2d2h kubeadm:kubelet-bootstrap 2d2h kubeadm:node-autoapprove-bootstrap 2d2h kubeadm:node-autoapprove-certificate-rotation 2d2h kubeadm:node-proxier 2d2h minikube-rbac 2d2h storage-provisioner 2d2h system:basic-user 2d2h
The clusterrole describes the Resources and the verbs that are accessible the user.
[vamshi@linux-r5z3:~] kubectl describe clusterrole cluster-admin
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
*.* [] [] [*]
[*] [] [*]
Listing the roles on Kubernetes:
[vamshi@master01 :~] kubectl get roles --all-namespaces NAMESPACE NAME AGE kube-public kubeadm:bootstrap-signer-clusterinfo 2d2h kube-public system:controller:bootstrap-signer 2d2h kube-system extension-apiserver-authentication-reader 2d2h kube-system kube-proxy 2d2h kube-system kubeadm:kubelet-config-1.15 2d2h kube-system kubeadm:nodes-kubeadm-config 2d2h kube-system system::leader-locking-kube-controller-manager 2d2h kube-system system::leader-locking-kube-scheduler 2d2h kube-system system:controller:bootstrap-signer 2d2h kube-system system:controller:cloud-provider 2d2h kube-system system:controller:token-cleaner 2d2h
We can further examine the rolebindings on the for the name: system::leader-locking-kube-scheduler which is being associated with the service account kube-scheduler.
[vamshi@master01 :~] kubectl describe rolebindings system::leader-locking-kube-scheduler -n kube-system Name: system::leader-locking-kube-scheduler Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true Role: Kind: Role Name: system::leader-locking-kube-scheduler Subjects: Kind Name Namespace ---- ---- --------- User system:kube-scheduler ServiceAccount kube-scheduler kube-system
There is a category of the api groups which contains the following api tags:
apiextensions.k8s.io, apps, autoscaling, batch, Binding, certificates.k8s.io, events.k8s.io, extensions, networking.k8s.io, PodTemplate, policy, scheduling.k8s.io, Secret, storage.k8s.io
The complete roles available in Kubernetes are as follows:
APIService, CertificateSigningRequest, ClusterRole, ClusterRoleBinding, ComponentStatus, ConfigMap, ControllerRevision, CronJob, CSIDriver, CSINode, CustomResourceDefinition, DaemonSet, Deployment, Endpoints, Event, HorizontalPodAutoscaler, Ingress, Job, Lease, LimitRange, LocalSubjectAccessReview, MutatingWebhookConfiguration, Namespace, NetworkPolicy, Node, PersistentVolume, PersistentVolumeClaim, Pod, PodDisruptionBudget, PodSecurityPolicy, PriorityClass, ReplicaSet, ReplicationController, ResourceQuota, Role, RoleBinding, RuntimeClass, SelfSubjectAccessReview, SelfSubjectRulesReview, Service, ServiceAccount, StatefulSet, StorageClass, SubjectAccessReview, TokenReview, ValidatingWebhookConfiguration and VolumeAttachment