Security¶

Operator webhook TLS¶

The operator’s validating webhook server requires a TLS certificate so that the Kubernetes API server can securely call it. This certificate is provisioned by cert-manager:

1. A self-signed Issuer (scylla-operator-selfsigned-issuer) is created in the scylla-operator namespace.

2. A Certificate (scylla-operator-serving-cert) is issued for the DNS name scylla-operator-webhook.scylla-operator.svc, stored in a Secret of the same name.

3. The ValidatingWebhookConfiguration has the annotation cert-manager.io/inject-ca-from: scylla-operator/scylla-operator-serving-cert, which tells cert-manager to inject the CA bundle into the webhook configuration so the Kubernetes API server trusts the webhook’s certificate.

cert-manager is a hard dependency of the operator unless it is deployed via OLM on OpenShift, which handles webhook certificate provisioning natively.

ScyllaDB cluster TLS¶

When the AutomaticTLSCertificates feature gate is enabled (default since v1.11, beta), the operator provisions a full PKI for each ScyllaDB cluster without requiring cert-manager. The operator manages certificates directly using its own internal certificate manager.

For each ScyllaDB datacenter (that is, each ScyllaCluster resource) the operator creates:

The operator watches all member Services and pod IPs and regenerates the serving certificate whenever the set of addresses changes (new pods, LoadBalancer address assignment, etc.).

Alternator TLS¶

When Alternator is enabled (spec.alternator in ScyllaCluster), the operator creates a separate serving CA and certificate:

The Alternator serving certificate is configured through spec.alternator.servingCertificate, which supports two modes:

• OperatorManaged (default): the operator provisions and rotates the Alternator serving certificate automatically. You can specify additionalDNSNames and additionalIPAddresses in operatorManagedOptions to include custom SANs.

• UserManaged: you provide your own TLS certificate in a kubernetes.io/tls Secret referenced by userManagedOptions.secretName. The operator mounts this Secret but does not manage its lifecycle — you are responsible for rotation.

CQL authentication¶

ScyllaDB authentication and authorization are not enabled by the operator by default. To enable them, provide a ConfigMap with a custom scylla.yaml that sets:

authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer

This ConfigMap is referenced in the ScyllaCluster spec and is merged with the operator-managed configuration.

When AutomaticTLSCertificates is enabled, CQL connections also require mutual TLS (client certificate authentication). This provides two layers of authentication: TLS client certificates at the transport level and username/password at the CQL protocol level.

Starting with ScyllaDB 2026.2, the default cassandra/cassandra superuser no longer exists by default. It is recommended to create application-specific roles with minimal privileges.

Alternator authorization¶

Alternator authorization is controlled by the insecureDisableAuthorization field in the Alternator spec:

• When authorization is enabled (the default for new clusters), Alternator requests must include valid AWS Signature Version 4 credentials. The credentials are derived from CQL roles — the username maps to the AWS access key, and the salted_hash of the password maps to the secret key.

• When insecureDisableAuthorization is set to true, any request is accepted without authentication. This is intended only for development and testing.

Operator ClusterRole¶

The scylladb:controller:operator ClusterRole is an aggregated ClusterRole that combines permissions from multiple component ClusterRoles selected by the label rbac.operator.scylladb.com/aggregate-to-scylla-operator: "true". This includes permissions to manage pods, Services, StatefulSets, PVCs, Secrets, ConfigMaps, Jobs, PodDisruptionBudgets, ServiceMonitors, PrometheusRules, and all ScyllaDB CRDs.

The operator runs as the scylla-operator ServiceAccount in the scylla-operator namespace, bound to the aggregate ClusterRole via a ClusterRoleBinding.

On OpenShift, additional permissions are added through a separate component ClusterRole (e.g., SecurityContextConstraints access).

Member ClusterRole¶

Each ScyllaDB pod runs with a dedicated ServiceAccount created for each ScyllaDB cluster (named <cluster-name>-member). This ServiceAccount is bound to the scyllacluster-member aggregate ClusterRole via a namespaced RoleBinding.

The member ClusterRole grants the sidecar running inside each ScyllaDB pod the minimum permissions it needs:

• Read pods, Secrets, ConfigMaps, Services, and StatefulSets — the sidecar reads its own identity, certificates, and cluster topology.

• Write pods and Services — the sidecar updates annotations on its own Service (host ID, token ring hash) and pod labels.

• Read internal node-status report resources — used for bootstrap synchronisation state.

User-facing ClusterRoles¶

The operator installs two ClusterRoles for Kubernetes users who manage ScyllaDB resources:

These ClusterRoles are aggregated into the default Kubernetes admin, edit, and view ClusterRoles. This means any user who has the Kubernetes edit role in a namespace can automatically create and manage ScyllaDB clusters in that namespace.

Monitoring ClusterRoles¶

Additional aggregate ClusterRoles exist for monitoring components:

• Prometheus (scylladb:monitoring:prometheus): permissions to read endpoints, pods, Services, and nodes. Required for Prometheus service discovery.

• Grafana (scylladb:monitoring:grafana): permissions to manage Grafana-related ConfigMaps and Secrets.

Authentication token¶

The operator generates a unique authentication token for each ScyllaCluster and stores it in a Secret named <cluster-name>-auth-token. This token is:

• Mounted into the Agent sidecar container as a configuration file.

• Used by ScyllaDB Manager to authenticate API calls to the Agent.

• Used by the operator itself when it communicates with the Agent (for example, to coordinate cleanup jobs).

In multi-DC deployments using multiple ScyllaCluster resources, ScyllaDB Manager needs a single token to communicate with all datacenters. You must manually extract the token from one datacenter’s <cluster-name>-auth-token Secret, patch it into the other datacenters’ Secrets, and then rolling-restart those datacenters so the Agent picks up the new token.

Shared namespace¶

ScyllaDB Manager is deployed in the scylla-manager namespace. It needs network access to the Agent API port (10001) on every ScyllaDB pod, regardless of namespace. The Manager does not require RBAC access to the Kubernetes API — it communicates directly with the Agents over HTTP using the authentication token.