> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/database-devops/3.0/use-db-devops/database-authentication-and-security/runtime-secrets.md).

# Runtime Secrets for DBOps

This guide explains how secrets (like registry credentials, clone script secrets, and database passwords) are managed securely at runtime in DBOps pipelines within Harness.

### Why runtime secrets matter <a href="#why-runtime-secrets-matter" id="why-runtime-secrets-matter"></a>

In Harness DBOps pipelines, secrets like container registry credentials, database passwords, and script tokens are needed to run your workflows. By default, these secrets are stored as Kubernetes Secrets and attached to the pods when they run.

For organizations with stricter compliance requirements or a desire to minimize secrets exposure, this feature lets you pass secrets directly to containers only when they are needed, without saving them in pod specs or Kubernetes manifests.

{% hint style="info" %}
**NOTE**

Once the step is completed, the pods are terminated and the secrets are removed from memory. This means that even if someone gains access to the pod, they will not be able to retrieve the secrets.
{% endhint %}

### Supported secret types <a href="#supported-secret-types" id="supported-secret-types"></a>

In DBOps workflows, the following types of secrets are typically required:

* **Container registry:** Used to pull images from private or public registries.
* **Schema repo clone secrets:** Used by scripts to fetch schema definitions from source control.
* **Database passwords:** Used for authenticating with databases via JDBC or similar connectors.

#### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

Ensure you have the following versions:

* **Harness Delegate**: 858xx or later
* **Harness CI Addon**: 1.16.81 or later
* **Harness CI Lite Engine**: 1.16.81 or later
* **Ng manager**: 1.87.0
* **Ci-manager**: 1.77.0

#### How it works <a href="#how-it-works" id="how-it-works"></a>

{% tabs %}
{% tab title="Container Registry" %}
By default, Kubernetes can pull public images from Docker Hub or similar public registries. However, for accessing private registries, explicit authentication is required.

Harness gives you the flexibility to skip passing container registry credentials from the pipeline - if your Kubernetes cluster is already configured to authenticate using a service account. This is done by creating a Kubernetes secret and attaching it to the service account used by the pods. This way, all pods using that service account can pull images from the private registry without needing to specify `imagePullSecrets` in each pod spec.

To configure Provide step group registry credentials to execution container, follow these steps:

1. Go to `Account Settings`.
2. Navigate to the Default setting and click on `Pipeline`.
3. Select the value `False` for **Provide step group registry credentials to execution container**. (Default value is `True`)

To manually configure registry access in your cluster:

1. Create the secret:

```bash
kubectl create secret generic registry-credential \
  --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
  --type=kubernetes.io/dockerconfigjson
```

2. Attach the secret to a service account:

```bash
kubectl patch serviceaccount default \
  -p '{"imagePullSecrets": [{"name": "registry-credential"}]}'
```

Once this setup is complete, all new pods using this service account will automatically use the secret to pull images from the private registry without needing `imagePullSecrets` in each pod spec.
{% endtab %}

{% tab title="Database Passwords" %}
Similar to how secrets are handled in custom scripts, Harness injects database passwords securely at runtime. By default, the database password is passed as an environment variable to the step container.

To enable runtime secret injection for database credentials, follow these steps:

1. Go to `Account Settings`.
2. Navigate to the Default setting and click on `Database DevOps`.
3. Select the value `True` for **Inject database secrets at runtime**.
   {% endtab %}

{% tab title="Custom Script Secrets" %}
With Harness, secrets used in DBSchema clone scripts are injected dynamically at runtime, meaning that they are not stored in:

* Pod spec
* Persistent environment variables

To enable runtime secret injection for database credentials, follow these steps:

1. Go to `Account Settings`.
2. Navigate to the Default setting and click on `Database DevOps`.
3. Select the value `True` for **Inject custom shell script secrets** at runtime.

Secrets are not retained after process execution. Even if someone runs `kubectl exec` into the pod, these values remain inaccessible.

{% hint style="info" %}
**IMPORTANT**

This feature only applies to DBSchema clone scripts. It does not apply to GitClone or Artifactory connector secrets. Go to [Add and reference file secrets](/harness-ai/use-harness-platform/secrets/add-file-secrets.md#reference-by-id) to understand how to add and reference file secrets in Harness pipelines.
{% endhint %}
{% endtab %}
{% endtabs %}

### Benefits <a href="#benefits" id="benefits"></a>

* Secrets are not stored in Kubernetes or pod specs.
* Enhanced security because secrets only live in memory for the duration of execution.
* Reduced surface area for secret leakage or misuse.

{% hint style="info" %}
**NOTE**

These benefits are realized only when runtime secret injection settings are explicitly enabled in the Database DevOps module under Account Settings.
{% endhint %}

### Next steps <a href="#next-steps" id="next-steps"></a>

* Go to [Set up connectors](/database-devops/3.0/setup-db-devops/jdbc-connection-string/set-up-connectors.md) to configure JDBC connectors that use secrets for database authentication.
* Go to [Provision Database DevOps](/database-devops/3.0/setup-db-devops/provision-database-devops.md) to set up schemas and instances that use these connectors.
