RBAC template#
Anaconda Enterprise dynamically provisions deployments, pods, services, secrets, and ingresses as part of its normal operation. As a result, it is important that the service account utilized by the application be given the necessary permissions to accomplish these operations.
For all operations except the ingress controller (more on this
below), it is sufficient to grant namespace-specific permissions.
The following Role
and RoleBinding
pair can be used to grant
permissions known to be sufficient to cover both installation and
regular operation. Replace <SERVICEACCOUNT>
and <NAMESPACE>
with their appropriate values:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: <SERVICEACCOUNT>
namespace: <NAMESPACE>
rules:
- verbs:
- get
- list
apiGroups:
- ''
resources:
- namespaces
- pods/log
- events
- verbs:
- create
- delete
- get
- list
- patch
- update
- watch
apiGroups:
- ''
resources:
- configmaps
- secrets
- pods
- persistentvolumeclaims
- endpoints
- services
- verbs:
- create
- delete
- get
- list
- patch
- update
- watch
apiGroups:
- apps
resources:
- deployments
- replicasets
- statefulsets
- verbs:
- create
- delete
- get
- list
- patch
- update
- watch
apiGroups:
- batch
resources:
- jobs
- cronjobs
- verbs:
- create
- delete
- get
- list
- patch
- update
- watch
apiGroups:
- extensions
resources:
- deployments
- replicasets
- verbs:
- create
- delete
- get
- list
- patch
- update
- watch
apiGroups:
- networking.k8s.io
resources:
- ingresses
- verbs:
- create
- delete
- get
- list
- patch
- update
- watch
apiGroups:
- route.openshift.io
resources:
- routes
- routes/custom-host
- verbs:
- get
- list
apiGroups:
- ''
resources:
- serviceaccounts
- roles
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: <SERVICEACCOUNT>
namespace: <NAMESPACE>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: <SERVICEACCOUNT>
subjects:
- kind: ServiceAccount
name: <SERVICEACCOUNT>
Note
Recent versions of OpenShift no longer allow granting direct access to the anyuid
Security Context Constraint (SCC), or any other default SCC. Instead, access grants are defined within the role. Below is an example configuration for the anyuid
SCC:
- verbs:
- use
apiGroups:
- security.openshift.io
resources:
- securitycontextconstraints
resourceNames:
- anyuid
If you wish to use the Anaconda-supplied ingress, it is also necessary
to grant a small number of additional, cluster-wide permissions.
That is because, as is typical with ingress controllers, this
controller expects to be able to monitor ingress-related resources
across all namespaces. The following is a minimal ClusterRole
and ClusterRoleBinding
pair that has been demonstrated to
grant the ingress controller sufficient permissions to run without
warnings:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: <SERVICEACCOUNT>-ingress
rules:
- verbs:
- '*'
apiGroups:
- '*'
resources:
- ingressclasses
- verbs:
- patch
apiGroups:
- '*'
resources:
- events
- verbs:
- list
- watch
apiGroups:
- '*'
resources:
- secrets
- endpoints
- ingresses
- services
- pods
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: <SERVICEACCOUNT>-ingress
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: <SERVICEACCOUNT>-ingress
subjects:
- kind: ServiceAccount
name: <SERVICEACCOUNT>
namespace: <NAMESPACE>
Please review these RBAC settings with your Kubernetes administrators. It is possible they can be further reduced, but no assumption should be made to that effect. Certainly, significant reductions in the scope of these permissions is likely to prevent correct operation of Anaconda Enterprise.