Explain:
Role-based access control (rbac) is a method for managing access to computer or network resources based on the role of a single user in an enterprise.
Kubernetes API.
Use in k8s
RBAC uses the rbac.authorization.k8s.io API group to drive authentication, allowing administrators to dynamically configure access policies through the Kubernetes API.
Versions after 1.8 are stable, and rbac.authorization.k8s.io/v1 is the API it uses. For k8s clusters to use RBAC authentication, it needs to be on the API server
Turn on this mode - authorization-mode=RBAC.
Overview of API
The RBAC API declares four top-level types that users can manipulate using kubectl, just like other resources.Can be created by kubectl apply-f (resource). YML
1.Role and ClusterRole
In the RBAC API, a role contains a series of permission controls, roles are defined in a namespace using roles, and cluster-wide uses cluster-wide to define the cluster's face-all-namespace role.
Give an example
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]
In this example, a pod-reader role is defined for default namespace using the Role type, and the rules used for the pods resource type include
["get", "watch", "list"]
ClusterRole can also grant control as a Role, but it is cluster-level and can be used as follows:
Cluster-scopedlevel resources such as node
Non-resource object endpoints
namespaced resources such as pod
Give an example
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"]
As mentioned above, a privilege control of type ClusterRole, called secret-reader, was created, and the rules used for secrets resource types include
["get", "watch", "list"]
2.RoleBinding and ClusterRoleBinding
Role binding s are privileges given to a user, or a set of users, and have a subjects concept that includes (users, groups, service accounts), a corresponding associated role that can work on a namespace, or ClusterRoleBinding. that works at the cluster level.
Give an example
apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "jane" to read pods in the "default" namespace. kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: jane # Name is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: 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
In the example above, a read-pods type of RoleBinding is created, working for default namespaces, which binds user jane to a Role type of pod-reader, allowing the user to have pod-reader privileges on pods within default.
apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "dave" to read secrets in the "development" namespace. kind: RoleBinding metadata: name: read-secrets namespace: development # This only grants permissions within the "development" namespace. subjects: - kind: User name: dave # Name is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Rolebinding can also reference the cluster role to grant permissions to the namespace resources defined in the cluster role in the rolebinding namespace.This allows administrators to define a set of common roles for the entire cluster and reuse them in multiple namespaces.
As above, even if the rolebinding below refers to a clusterrole, dave can only read secretes from the development namespace (the namespace of rolebinding).
This has the advantage that all rights can be managed in a unified way, and specific authorizations can be given at the appropriate time to facilitate management.
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
Finally, you can use clusterRoleBinding to grant permissions at the cluster level and in all namespaces.The ClusterRoleBinding above allows any user in the group Manager to read secrets in any namespace.
One more thing to note:
The role referenced by the bound object or the cluster role cannot be modified.Attempting to change the roleref field of a bound object will result in validation errors.To change the roleref field on an existing bound object, you must delete and recreate the bound object.
Aggregated ClusterRoles
Starting with 1.9, you can use aggregationrule to combine other clusterroles to create clusterroles.The aggregated ClusterRoles'permissions are managed by the controller and populated by federating any ClusterRole rules that match the provided tag selector.Aggregated ClusteterRole example
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: monitoring aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-monitoring: "true" rules: [] # Rules are automatically filled in by the controller manager.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: aggregate-cron-tabs-edit labels: # Add these permissions to the "admin" and "edit" default roles. rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rules: - apiGroups: ["stable.example.com"] resources: ["crontabs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view labels: # Add these permissions to the "view" default role. rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: ["stable.example.com"] resources: ["crontabs"] verbs: ["get", "list", "watch"]
Examples of Role's various uses
rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]
rules: - apiGroups: ["extensions", "apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] - apiGroups: ["batch", "extensions"] resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
rules: - apiGroups: [""] resources: ["configmaps"] resourceNames: ["my-config"] verbs: ["get"]
Referring to Subjects
rolebinding or clusterrolebinding binds roles to subjects.The subject can be a group, user, or service account.
The user is represented by a string.They can be simple user names such as'alice', e-mail style names such as'bob@example.com', or digital identities represented as strings.The authentication module is configured by the kubernetes administrator to generate user names in the desired format.The rbac authorization system does not require any specific format.
However, the prefix system: is reserved for use by the kubernetes system, so administrators should ensure that user names do not accidentally include this prefix.
Group information in kubernetes is currently provided by the authenticator module.Like users, groups are represented as strings, which have no formatting requirements but retain the prefix system:.
The user name of the service account is prefixed with system:serviceCaccount:prefix and belongs to a group prefixed with system:serviceCaccounts:prefix.
Role Binding example
Show only the subjetc section
subjects: - kind: User name: "alice@example.com" apiGroup: rbac.authorization.k8s.io
subjects: - kind: Group name: "frontend-admins" apiGroup: rbac.authorization.k8s.io
subjects: - kind: ServiceAccount name: default namespace: kube-system
For all service accounts in the "qa" namespace
subjects: - kind: Group name: system:serviceaccounts:qa apiGroup: rbac.authorization.k8s.io
For all accounts in the cluster
subjects: - kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io
For all users
subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io - kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io
All Controller Roles in Cluster
system:controller:attachdetach-controller system:controller:certificate-controller system:controller:clusterrole-aggregation-controller system:controller:cronjob-controller system:controller:daemon-set-controller system:controller:deployment-controller system:controller:disruption-controller system:controller:endpoint-controller system:controller:expand-controller system:controller:generic-garbage-collector system:controller:horizontal-pod-autoscaler system:controller:job-controller system:controller:namespace-controller system:controller:node-controller system:controller:persistent-volume-binder system:controller:pod-garbage-collector system:controller:pv-protection-controller system:controller:pvc-protection-controller system:controller:replicaset-controller system:controller:replication-controller system:controller:resourcequota-controller system:controller:root-ca-cert-publisher system:controller:route-controller system:controller:service-account-controller system:controller:service-controller system:controller:statefulset-controller system:controller:ttl-controller
Common command lines
Create a Role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods:
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
Create a Role named "pod-reader" with resourceNames specified:
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
Create a Role named "foo" with apiGroups specified:
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
Create a Role named "foo" with subresource permissions:
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name:
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
Creates a ClusterRole object. Examples:
Create a ClusterRole named "pod-reader" that allows user to perform "get", "watch" and "list" on pods:
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
Create a ClusterRole named "pod-reader" with resourceNames specified:
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
Create a ClusterRole named "foo" with apiGroups specified:
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
Create a ClusterRole named "foo" with subresource permissions:
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
Create a ClusterRole name "foo" with nonResourceURL specified:
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
Create a ClusterRole name "monitoring" with aggregationRule specified:
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
Grants a Role or ClusterRole within a specific namespace. Examples:
Within the namespace "acme", grant the permissions in the admin ClusterRole to a user named "bob":
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
Within the namespace "acme", grant the permissions in the view ClusterRole to the service account in the namespace "acme" named "myapp" :
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
Within the namespace "acme", grant the permissions in the view ClusterRole to a service account in the namespace "myappnamespace" named "myapp":
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
kubectl create clusterrolebinding
Grants a ClusterRole across the entire cluster, including all namespaces. Examples:
Across the entire cluster, grant the permissions in the cluster-admin ClusterRole to a user named "root":
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
Across the entire cluster, grant the permissions in the system:node-proxier ClusterRole to a user named "system:kube-proxy":
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
Across the entire cluster, grant the permissions in the view ClusterRole to a service account named "myapp" in the namespace "acme":
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
Service Account Permissions
The default rbac policy grants scope permissions to control flat components, nodes, and controllers, but does not grant permissions to service accounts outside the kube system namespace (beyond the discovery permissions granted to all authenticated users).
This allows you to grant specific roles to specific service accounts as needed.Fine-grained role bindings provide higher security but require more management.Using service account makes permissions more container managed
For example, grant read-only permissions within "My namespace" to the "My SA" service account
kubectl create rolebinding my-sa-view \ --clusterrole=view \ --serviceaccount=my-namespace:my-sa \ --namespace=my-namespace
Granting default service account
Use the Default service account if the application does not specify a ServiceAccountName
kubectl create rolebinding default-view \ --clusterrole=view \ --serviceaccount=my-namespace:default \ --namespace=my-namespace
Grant super administrator privileges to the default account in kube-system
kubectl create clusterrolebinding add-on-cluster-admin \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:default
Assign to all service accounts in the specified namespace
kubectl create rolebinding serviceaccounts-view \ --clusterrole=view \ --group=system:serviceaccounts:my-namespace \ --namespace=my-namespace
Grant super users access to all service accounts within the cluster (strongly recommended)
kubectl create clusterrolebinding serviceaccounts-cluster-admin \ --clusterrole=cluster-admin \ --group=system:serviceaccounts