Role-based access control¶
Role-based access control (RBAC) is used to control access to Kubernetes API resources in a cluster.
Permissions are granted via Roles
and ClusterRoles
.
Permissions cannot be denied, only granted to a role.
To create these resources, you must be a cluster administrator. To install the charts into a cluster for which you do not have a Cluster Admin role, disable creation of these resources, and instead reference an account created for you.
Role Based Access Control on Kubernetes
Role and ClusterRole¶
An RBAC Role is set at a namespace
level.
Grant a Role permissions to one or many API namespaces by setting the apiGroup
field in the RBAC definition.
A ClusterRole is granted permissions in the same way as a Role however the permissions are applied at a cluster
level.
This lets you grant additional resources to the ClusterRole
, such as nodes.
For example:
rules:
- apiGroups: [""]
In our examples we set this to an empty string. This applies the rule across all namespaces.
Rules are then applied on a Kubernetes resource level.
rules:
- apiGroups: [""]
resources: ["endpoints", "services"]
The example applies the rule to the endpoints
and services
resources in the API server.
You can also configure a named resource.
rules:
- apiGroups: [""]
resources: ["services"]
resourceNames: ["ticker-tp"]
To complete the Role permissions we need to add verbs to the rule.
rules:
- apiGroups: [""]
resources: ["endpoints", "services"]
verbs: ["get", "watch", "list"]
Here we allow the Role to list all endpoints and services, and to retrieve details on a resource within the namespace.
RoleBinding and ClusterRoleBinding¶
A Role or ClusterRole by itself does not allow an entity permissions: a user must then be bound to that Role.
Subjects are bound to a Role in a RoleBinding or ClusterRole in a ClusterRoleBinding.
A subject may be a user
, group
or a serviceAccount
.
In our example we use a serviceAccount
to allow access to the Kubernetes API.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: gw-kx-viewer
subjects:
- kind: ServiceAccount
name: gw-kx
apiGroup: ""
roleRef:
kind: Role
name: gw-kx-viewer
apiGroup: ""
This gives the service account gw-kx
the Role of gw-kx-viewer
, granting that service account all the permissions of the Role.
Service account¶
A service account differs from a user entity. A user account is for a human user of the Kubernetes cluster, active over the entire cluster. A service account is for a pod process and is active only within a namespace.
By default, when a pod is not assigned a service account the default is assigned.
Regardless if it is a named or default service account assigned to the pod, the permissions and secrets of that service account are granted and mounted to the pod.
A secrets volume is mounted for the given service account:
/var/run/secrets/kubernetes.io/serviceaccount
This contains items such as access tokens which can be used to authenticate and permit querying the Kubernetes API server.
Helm configuration¶
The charts allow for service accounts SAs and RBAC resources to be created. The charts use RBAC to permit the containers to query the Kubernetes API.
Within each component Helm chart a RBAC Role
and RoleBinding
has been templated for a service account related to that chart.
Role:
name: {{ include "gw.fullname" . }}-viewer
RoleBinding:
name: {{ include "gw.fullname" . }}-viewer
ServiceAccount:
name: {{ include "gw.serviceAccountName" . }}
To enable the creation of the RBAC roles and service account, update the component values file:
serviceAccount:
create: true
rbac:
create: true
You can also use the global.rbac.create
boolean to enable or disable the creation of
these RBAC resources.
Alternatively if RBAC and service accounts have previously been created for you by a cluster admin, the relevant service account can be set by updating your component values file.
serviceAccount:
# The name of the service account to use.
# If not set and create is true, a name is generated using the fullname template
name: "my-service-account"