Configure narrow-scope Role-Based Access Control (RBAC) for Helm upgrades

This guide explains how to configure narrow-scope Role-Based Access Control (RBAC) permissions that allow application teams to upgrade Mission Control Helm releases without requiring cluster-admin privileges.

By default, Helm operations that manage Custom Resource Definitions (CRDs) require cluster-admin privileges because CRDs are cluster-scoped resources. This creates a security concern in environments where application teams should not have broad cluster-level permissions.

A narrow-scope RBAC configuration addresses these issues and provides several security benefits:

Principle of least privilege: Application teams have only the permissions required for Helm upgrades.
Namespace-scoped permissions: Helm release management and workload operations are restricted to the namespace.
CRD isolation: Access is restricted to only the specific CRDs shipped with Mission Control, preventing modification of other cluster-wide resources.
Operator isolation: Access is restricted to only the cass-operator and k8ssandra-operator ClusterRoles and ClusterRoleBindings.
Separation of privileges: Clear boundaries between platform administrators and application teams.
Audit trail: All operations are performed under a dedicated ServiceAccount, enabling clear audit logging.

This configuration uses the resourceNames field in ClusterRole definitions to explicitly list the allowed CRDs and operator RBAC resources, preventing access to other cluster-wide resources.

Teams with access to the helm-upgrader ServiceAccount can:

Modify any Mission Control workload in the namespace.
Update the specified CRDs.
Create or delete resources within the namespace.

Ensure that you properly control and audit access to the ServiceAccount token.

Prerequisites

Cluster-admin access to create ClusterRoles and ClusterRoleBindings for initial setup
Mission Control installed with Helm
Familiarity with Kubernetes RBAC concepts

RBAC components

The narrow-scope RBAC configuration consists of four components:

ServiceAccount: A dedicated service account (helm-upgrader) that application teams use to perform Helm upgrades.
Role: A namespace-scoped Role that grants permissions for Helm release management, workloads, and Mission Control components within the namespace.
ClusterRole: A cluster-scoped ClusterRole that grants access to only the 18 CRDs shipped by Mission Control and the cass-operator and k8ssandra-operator ClusterRoles and ClusterRoleBindings using the resourceNames field for narrow scope.
Bindings: A RoleBinding and ClusterRoleBinding that connect the ServiceAccount to the Role and ClusterRole.

Install RBAC configuration

Download the RBAC configuration files:

Review the ClusterRole to verify it includes only the CRDs and operator RBAC resources your Mission Control version requires:

cat rbac/helm-upgrade-clusterrole.yaml

The ClusterRole includes the following CRDs:

resourceNames:
  # K8ssandra CRDs
  - "k8ssandraclusters.k8ssandra.io"
  - "k8ssandratasks.control.k8ssandra.io"
  - "cassandradatacenters.cassandra.datastax.com"
  - "cassandratasks.control.k8ssandra.io"
  - "scheduledtasks.control.k8ssandra.io"
  - "clientconfigs.config.k8ssandra.io"
  - "replicatedsecrets.replication.k8ssandra.io"
  - "stargates.stargate.k8ssandra.io"
  - "reapers.reaper.k8ssandra.io"
  # Medusa CRDs
  - "medusabackupjobs.medusa.k8ssandra.io"
  - "medusabackups.medusa.k8ssandra.io"
  - "medusabackupschedules.medusa.k8ssandra.io"
  - "medusaconfigurations.medusa.k8ssandra.io"
  - "medusarestorejobs.medusa.k8ssandra.io"
  - "medusatasks.medusa.k8ssandra.io"
  # Mission Control CRDs
  - "missioncontrolclusters.missioncontrol.datastax.com"
  - "cqlconnectivities.missioncontrol.datastax.com"
  - "dataapis.missioncontrol.datastax.com"

The ClusterRole also includes narrow-scope access to operator ClusterRoles and ClusterRoleBindings:

# ClusterRole management for operators
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["get", "list", "create", "update", "patch", "delete"]
  resourceNames:
    - "cass-operator-cluster-role"
    - "k8ssandra-operator-cluster-role"

# ClusterRoleBinding management for operators
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterrolebindings"]
  verbs: ["get", "list", "create", "update", "patch", "delete"]
  resourceNames:
    - "cass-operator-cluster-role"
    - "k8ssandra-operator-cluster-role"

Apply the RBAC configuration as a cluster administrator:

kubectl apply -f rbac/helm-upgrade-role.yaml
kubectl apply -f rbac/helm-upgrade-clusterrole.yaml
kubectl apply -f rbac/helm-upgrade-bindings.yaml

Verify that the system created the RBAC resources:

kubectl get serviceaccount helm-upgrader -n mission-control
kubectl get role helm-release-upgrader -n mission-control
kubectl get clusterrole helm-crd-upgrader
kubectl get rolebinding helm-release-upgrader -n mission-control
kubectl get clusterrolebinding helm-crd-upgrader

Perform Helm upgrades with narrow-scope RBAC

After you configure the RBAC resources, application teams can perform Helm upgrades using the helm-upgrader ServiceAccount without cluster-admin privileges.

Create a kubeconfig that uses the helm-upgrader ServiceAccount:

kubectl create token helm-upgrader -n mission-control --duration=1h > /tmp/helm-upgrader-token

Set the token as an environment variable:

export HELM_KUBECONFIG_TOKEN=$(cat /tmp/helm-upgrader-token)

Perform the Helm upgrade using the ServiceAccount credentials:

helm upgrade mission-control \
  oci://registry.replicated.com/mission-control/mission-control \
  --version 1.19.1 \
  --namespace mission-control \
  -f values.yaml \
  --kube-token="${HELM_KUBECONFIG_TOKEN}" \
  --timeout 15m

Alternatively, configure your CI/CD pipeline to use the ServiceAccount token for automated upgrades.

Maintain CRD permissions for new versions

When you upgrade to a new Mission Control version that introduces additional CRDs, you must update the ClusterRole resourceNames list before performing the upgrade.

To add new CRDs to the ClusterRole, do the following:

Identify new CRDs in the chart version:
```
helm show crds oci://registry.replicated.com/mission-control/mission-control \
  --version NEW_VERSION
```
Replace NEW_VERSION with the version number of the chart you are upgrading to.
Edit the ClusterRole to add the new CRD names to the resourceNames list:
```
kubectl edit clusterrole helm-crd-upgrader
```

Verify the updated ClusterRole:

kubectl get clusterrole helm-crd-upgrader -o yaml

Proceed with the Helm upgrade using the narrow-scope RBAC.

Troubleshooting

You might encounter the following issues when using narrow-scope RBAC for Helm upgrades:

Permission denied errors during upgrade

If you encounter permission errors during a Helm upgrade, verify the following:

The ServiceAccount token is valid and not expired
The Role includes permissions for all required namespace-scoped resources
The ClusterRole includes all CRDs required by the chart version
The RoleBinding and ClusterRoleBinding reference the correct ServiceAccount

To debug permission issues, run the following commands:

kubectl auth can-i get customresourcedefinitions \
  --as=system:serviceaccount:mission-control:helm-upgrader

kubectl auth can-i create deployments -n mission-control \
  --as=system:serviceaccount:mission-control:helm-upgrader

New CRDs not accessible

If a new Mission Control version introduces CRDs that are not in the resourceNames list of the ClusterRole, then the upgrade fails with permission errors.

To resolve this issue, update the ClusterRole to include the new CRD names before you attempt the upgrade.