In Kubernetes, role-based access control (RBAC) regulates access to cluster resources. This page details how to configure both the Appian operator Helm chart and Appian custom resources to customize Kubernetes RBAC to account for a variety of use cases. It is aimed at self-managed customers running Appian on Kubernetes.
By default, the Appian operator Helm chart configures the Appian operator to reconcile Appian custom resources across the entire cluster. Specifically, it deploys a ClusterRole and ClusterRoleBinding instead of a Role and RoleBinding so that the operator can reconcile custom resources across all namespaces.
To configure the Appian operator to reconcile only custom resources in the namespace in which it is deployed, set controllers.rbac.clusterWideAccess to false
when installing the chart. This is useful when you intend to deploy all Appian custom resources in a single namespace in order to limit the access needed by the Appian operator.
By default, the Appian operator Helm chart deploys ClusterRoles that aggregate to the built-in view, edit, and admin ClusterRoles. This enables principals with those roles to interact with Appian custom resources.
To disable this feature, set rbac.aggregatedClusterRoles.enabled to false
when installing the chart.
Both the Appian operator Helm chart and Appian CRD support binding the operator and Appian, respectively, to arbitrary roles and cluster roles. This is particularly useful when you need to make either the Appian operator or Appian use a specific pod security policy (PSP).
Imagine that you need to configure the Appian operator to use a PSP that you've created called my-psp
. First, define either a ClusterRole or Role that authorizes use of your PSP by creating a file named use-my-psp.yaml
with the following content:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: rbac.authorization.k8s.io/v1
# Use Role instead of ClusterRole if you'd like to disallow bindings across the entire cluster
kind: ClusterRole
metadata:
name: use-my-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
verbs:
- use
resourceNames:
- my-psp
Then, create the ClusterRole or Role via kubectl create
or kubectl apply
:
kubectl create -f path/to/use-my-psp.yaml
kubectl apply -f path/to/use-my-psp.yaml
If you defined a Role instead of a ClusterRole, make sure to include the --namespace
/-n
flag to specify the namespace in which you've installed, or will install, the Appian operator Helm chart.
Finally, pass the name of the ClusterRole or Role, use-my-psp
, via one or more of the following properties when installing or upgrading the chart:
If you want to bind the operator's controllers, use controllers.rbac.clusterRoles
or controllers.rbac.roles
. If you want to bind the operator's webhooks, use webhooks.rbac.clusterRoles
or webhooks.rbac.roles
. If you defined a Role instead of a ClusterRole, use controllers.rbac.roles
or webhooks.rbac.roles
instead of controllers.rbac.clusterRoles
or webhooks.rbac.clusterRoles
.
This will instruct the chart to include a RoleBinding that binds the use-my-psp
ClusterRole or Role to one of the operator's service accounts.
You can check that the operator's controller and/or webhook pod(s) are using the my-psp
PSP by checking the value of their kubernetes.io/psp
annotation:
1
kubectl -n <NAMESPACE> get pod <POD> -ojsonpath={.metadata.annotations.'kubernetes\.io/psp'}
Now imagine that you need to configure Appian to use a PSP that you've created called my-psp
. First, follow the steps from the section above to define and create either a ClusterRole or Role that authorizes use of your PSP. If you defined a Role instead of a ClusterRole, make sure to include the --namespace
/-n
flag when running kubectl create
or kubectl apply
to specify the namespace in which you've created or will create the Appian custom resource.
The Appian operator and Appian CRD support binding Appian to existing ClusterRoles and Roles via the .spec.rbac.clusterRoles and .spec.rbac.roles fields, respectively, on Appian custom resources. When specified, the fields instruct the operator to create one or more RoleBinding resources that bind the provided ClusterRole(s) and/or Role(s) to the service account associated with the custom resource.
The operator, however, lacks access to do so by default. When installing or upgrading the Appian operator chart, pass the name(s) of the ClusterRole(s) and/or Role(s) to which you'd like any Appian sites to be bound via .controllers.rbac.bind.clusterRoles and/or controllers.rbac.bind.roles. This will instruct the chart to include a rule that allows the operator to bind to the provided ClusterRole(s) and/or Role(s).
Therefore, to allow the operator to bind to the use-my-psp
ClusterRole or Role, pass use-my-psp
via either controllers.rbac.bind.clusterRoles or controllers.rbac.bind.roles when installing or upgrading the chart.
Now, you’re ready to create the Appian custom resource. Define your custom resource in a file named appian.yaml
with the following RBAC-related content:
1
2
3
4
5
6
7
8
9
apiVersion: crd.k8s.appian.com/v1alpha1
kind: Appian
metadata:
name: appian-k8s-psp
spec:
rbac:
# Use roles instead of clusterRoles if you defined a Role instead of a ClusterRole
clusterRoles:
- use-my-psp
Finally, run kubectl create
or kubectl apply
to create or update the Appian custom resource:
1
kubectl -n <NAMESPACE> create -f path/to/appian.yaml
1
kubectl -n <NAMESPACE> apply -f path/to/appian.yaml
If you defined a Role instead of a ClusterRole, make sure <NAMESPACE>
matches the namespace in which you created the Role.
You can check that the pods associated with the custom resource are using the my-psp
PSP by checking the value of their kubernetes.io/psp
annotation:
1
kubectl -n <NAMESPACE> get pod <POD> -ojsonpath={.metadata.annotations.'kubernetes\.io/psp'}