Skip to main content

​
Configure lifecycle

These fields control whether the operator actively configures and starts RegattaDB, or leaves it untouched while still managing the surrounding Kubernetes resources. Use them to stage a RegattaCluster resource before go-live, or to stop RegattaDB for planned maintenance without deleting anything.

​
Configure security

Every Pod also always runs as non-root and uses the OnRootMismatch file system group-change policy, so mounted volumes are already owned by the right group when the container starts. Neither is configurable; both apply regardless of what you set under spec.security.

​
Security context and credentials

Every RegattaDB Pod runs with the settings from spec.security: non-root UID/GID, the seccomp profile, and allowPrivilegeEscalation, as configured. Pods do not mount a Kubernetes ServiceAccount token, because RegattaDB itself never calls the Kubernetes API. The operator’s own namespaced permissions let it manage the resources described throughout this section: Services, StatefulSets, ConfigMaps, the credentials Secret, and your RegattaCluster status. Its only access outside that namespace is the cluster-scoped read-only permission described in Prerequisites and Installation.
The initial RegattaDB administrator credentials, stored in a Secret named like my-regattadb-credentials, are deterministic rather than randomly generated per installation. Read them from that Secret rather than assuming a fixed value, and handle it with the same care as any other credential in your Kubernetes cluster. Never print the contents of the credentials Secret while troubleshooting.