> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/references/dataos-resources/secret.md).

# Secret

## Overview

A Secret keeps credentials out of other Resource manifests. You can define the Secret itself in YAML, but you store the sensitive value once in that Secret and reference the Secret by name from other Resources. That separation is the point: credentials stay centralized instead of being repeated across manifests, which reduces accidental exposure when Resources are created, viewed, or edited.

{% hint style="info" %}
**Secret in the Data Product Lifecycle**

In the Data Product Lifecycle, Secrets play a crucial role in securely managing credentials and sensitive information. They are particularly useful when your Data Product requires:

* **Secure credential management**: Storing and managing sensitive information such as usernames, passwords, API keys, or certificates securely within a Tenant. For example, a Secret can securely store the credentials needed to connect to a database, ensuring they are not exposed in the codebase or configuration files.
* **Access control**: Ensuring that only authorized components and services within the tenant can access the credentials. For instance, a Secret can be used to provide a web application with the credentials to access a third-party service without exposing those credentials to the broader environment.
  {% endhint %}

## Access requirements

Before creating or managing a Secret, ensure you have the required permissions. See [Secret: Access control](https://v2.dataos.info/operate/access-model/resource-level-permissions/secret-access-control).

## Structure of a Secret manifest file <a href="#structure-of-a-secret-manifest" id="structure-of-a-secret-manifest"></a>

A Secret manifest carries the standard Resource fields (`name`, `version`, `type: secret`) plus a `spec` that holds the credential as key-value pairs. For the full field-by-field breakdown, see [Attributes of a Secret manifest](/references/dataos-resources/secret/manifest-configuration.md). To create one for a specific use case, start with the relevant guide below.

## How to create a Secret? <a href="#how-to-create-a-secret" id="how-to-create-a-secret"></a>

Choose the guide that matches where the Secret will be used.

* [Data sources](/references/dataos-resources/secret/data-sources.md): Source-specific Secret guides for supported data sources.
* [Repositories](/references/dataos-resources/secret/repositories.md): Secret guides for hosted repository credentials.
* [Projections](/references/dataos-resources/secret/projections.md): Runtime projection patterns for exposing selected Secret values to workloads.

## Configurations <a href="#configurations" id="configurations"></a>

Secret can be configured to secure credential information through key-value pairs. For a detailed breakdown of the configuration options and attributes, see [Attributes of Secret manifest](/references/dataos-resources/secret/manifest-configuration.md).

## Best practices <a href="#best-practices" id="best-practices"></a>

This section involves dos and don'ts for managing a Secret.

* Before deleting a Secret, ensure that any other Resources are not using it.

## FAQs <a href="#faqs" id="faqs"></a>

**1. Can I update an existing Secret?**

Yes, you can update a Secret by modifying its manifest file and re-applying it. However, ensure that dependent Resources are updated accordingly. To update a Secret, after making changes in the manifest file, execute the following command.

```bash
dataos-ctl resource apply -f {path-to-manifest-file} 
```

**2. What happens if a Secret is deleted?**

If a Secret is deleted, any Resources relying on it may lose access or experience failures. It is recommended to verify dependencies before deletion.

**3. Is there a way to restore a deleted Secret?**

No, deleted Secrets cannot be recovered. You must create a new Secret and update all associated resources.

**4. Can we create multiple Secrets with the same name?**

No, for Secrets, names must be unique. If you attempt to create a Secret with a name that already exists, the system will prevent duplication. You may need to use a different name or update the existing Secret if modifications are required.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/references/dataos-resources/secret.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.