> ## Documentation Index
> Fetch the complete documentation index at: https://docs.regatta.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Security & Lifecycle

> Configure the Pod security context, RegattaDB's credentials, and whether the operator starts or stops it.

## 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.

| Field                      | Default | Description                                                                                                                                                                                        |
| -------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `spec.lifecycle.configure` | `true`  | Whether the operator configures RegattaDB through the System Manager once Kubernetes is ready. Set `false` only when creating a new, stopped RegattaCluster resource, together with `start: false` |
| `spec.lifecycle.start`     | `true`  | Whether the operator starts RegattaDB after configuring it. Set `false` to keep Kubernetes Pods running with RegattaDB stopped                                                                     |

## Configure security

| Field                                    | Default          | Description                                                                                                                                                            |
| ---------------------------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `spec.security.runAsUser`                | `1000`           | The non-root Linux UID RegattaDB processes run as                                                                                                                      |
| `spec.security.runAsGroup`               | `1001`           | The non-root Linux GID RegattaDB processes run as                                                                                                                      |
| `spec.security.fsGroup`                  | `1001`           | The filesystem group applied to mounted storage                                                                                                                        |
| `spec.security.seccompProfile`           | `RuntimeDefault` | A seccomp profile restricts which Linux syscalls a container may make; `RuntimeDefault` applies Kubernetes' standard restricted set, or use `Unconfined` to disable it |
| `spec.security.allowPrivilegeEscalation` | `false`          | Whether a RegattaDB process can gain more privileges than its parent (for example through a setuid binary). Keep `false` for production                                |

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](../prerequisites.mdx) and [Installation](../installation.mdx).

<Danger>
  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.
</Danger>