146 lines
5.2 KiB
Markdown
146 lines
5.2 KiB
Markdown
# Kubernetes Role-Based Access Control (RBAC)
|
||
|
||
## Role-Based Access Control (RBAC)
|
||
|
||
Kubernetes has an **authorization module named Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) that helps to set utilization permissions to the API server.\
|
||
The RBAC table is constructed from “**Roles**” and “**ClusterRoles**.” The difference between them is just where the role will be applied – a “**Role**” will grant access to only **one** **specific** **namespace**, while a “**ClusterRole**” can be used in **all namespaces** in the cluster. Moreover, ClusterRoles can also grant access to:
|
||
|
||
* cluster-scoped resources (like nodes).
|
||
* non-resource endpoints (like /healthz).
|
||
* namespaced resources (like Pods), across all namespaces.
|
||
|
||
Example of **Role** **configuration**:
|
||
|
||
```yaml
|
||
apiVersion: rbac.authorization.k8s.io/v1
|
||
kind: Role
|
||
metadata:
|
||
namespace: defaultGreen
|
||
name: pod-and-pod-logs-reader
|
||
rules:
|
||
- apiGroups: [""]
|
||
resources: ["pods", "pods/log"]
|
||
verbs: ["get", "list", "watch"]
|
||
```
|
||
|
||
Example of **ClusterRole** configuration:
|
||
|
||
```yaml
|
||
apiVersion: rbac.authorization.k8s.io/v1
|
||
kind: ClusterRole
|
||
metadata:
|
||
# "namespace" omitted since ClusterRoles are not namespaced
|
||
name: secret-reader
|
||
rules:
|
||
- apiGroups: [""]
|
||
resources: ["secrets"]
|
||
verbs: ["get", "watch", "list"]
|
||
```
|
||
|
||
For example you can use a **ClusterRole** to allow a particular user to run:
|
||
|
||
```
|
||
kubectl get pods --all-namespaces
|
||
```
|
||
|
||
**Role and ClusterRole Binding concept**
|
||
|
||
A **role binding** **grants the permissions defined in a role to a user or set of users**. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A **RoleBinding** grants permissions within a specific **namespace** whereas a **ClusterRoleBinding** grants that access **cluster-wide**.
|
||
|
||
**RoleBinding** example:
|
||
|
||
```yaml
|
||
apiVersion: rbac.authorization.k8s.io/v1
|
||
# This role binding allows "jane" to read pods in the "default" namespace.
|
||
# You need to already have a Role named "pod-reader" in that namespace.
|
||
kind: RoleBinding
|
||
metadata:
|
||
name: read-pods
|
||
namespace: default
|
||
subjects:
|
||
# You can specify more than one "subject"
|
||
- kind: User
|
||
name: jane # "name" is case sensitive
|
||
apiGroup: rbac.authorization.k8s.io
|
||
roleRef:
|
||
# "roleRef" specifies the binding to a Role / ClusterRole
|
||
kind: Role #this must be Role or ClusterRole
|
||
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
|
||
apiGroup: rbac.authorization.k8s.io
|
||
```
|
||
|
||
**ClusterRoleBinding** example:
|
||
|
||
```yaml
|
||
apiVersion: rbac.authorization.k8s.io/v1
|
||
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
|
||
kind: ClusterRoleBinding
|
||
metadata:
|
||
name: read-secrets-global
|
||
subjects:
|
||
- kind: Group
|
||
name: manager # Name is case sensitive
|
||
apiGroup: rbac.authorization.k8s.io
|
||
roleRef:
|
||
kind: ClusterRole
|
||
name: secret-reader
|
||
apiGroup: rbac.authorization.k8s.io
|
||
```
|
||
|
||
**Permissions are additive** so if you have a clusterRole with “list” and “delete” secrets you can add it with a Role with “get”. So be aware and test always your roles and permissions and **specify what is ALLOWED, because everything is DENIED by default.**
|
||
|
||
### **Enumerating RBAC**
|
||
|
||
```bash
|
||
# Get current privileges
|
||
kubectl auth can-i --list
|
||
## use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account
|
||
|
||
# List Cluster Roles
|
||
kubectl get clusterroles
|
||
kubectl describe clusterroles
|
||
|
||
# List Cluster Roles Bindings
|
||
kubectl get clusterrolebindings
|
||
kubectl describe clusterrolebindings
|
||
|
||
# List Roles
|
||
kubectl get roles
|
||
kubectl describe roles
|
||
|
||
# List Roles Bindings
|
||
kubectl get rolebindings
|
||
kubectl describe rolebindings
|
||
```
|
||
|
||
### RBAC Structure
|
||
|
||
RBAC’s permission is built from three individual parts:
|
||
|
||
1. **Role\ClusterRole –** The actual permission. It contains _**rules**_ that represent a set of permissions. Each rule contains [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) and [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). The verb is the action that will apply on the resource.
|
||
2. **Subject (User, Group or ServiceAccount) –** The object that will receive the permissions.
|
||
3. **RoleBinding\ClusterRoleBinding –** The connection between Role\ClusterRole and the subject.
|
||
|
||
This is what it will look like in a real cluster:
|
||
|
||
|
||
|
||
“**Fine-grained** role bindings **provide greater security**, but **require more effort to administrate**."
|
||
|
||
From **Kubernetes** 1.6 onwards, **RBAC** policies are **enabled by default**. **** But to enable RBAC you can use something like:
|
||
|
||
```
|
||
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
||
```
|
||
|
||
This is enabled by default. RBAC functions:
|
||
|
||
* Restrict the access to the resources to users or ServiceAccounts.
|
||
* An RBAC Role or ClusterRole contains rules that represent a set of permissions.
|
||
* Permissions are purely additive (there are no “deny” rules).
|
||
* RBAC works with Roles and Bindings
|
||
|
||
{% hint style="info" %}
|
||
When configuring roles and permissions it's highly important to always follow the principle of Least Privileges
|
||
{% endhint %}
|