Manage Secrets

Manage Secrets#

Secrets in the platform provide a secure way to store sensitive information such as API keys, database credentials, or tokens. They are created at the organizational level and can then be assigned to one or more projects. This ensures workloads always have the credentials they need without exposing them directly in code or manifests.

Secrets page#

The main secrets page displays all secrets in your organization. Each entry includes key details such as the secret’s name, type, current status, scope, assigned projects, and last updated time. You can filter or search secrets by name or type, and use pagination to browse through the list.

The main secrets list displays all available secrets.

Secrets table#

Column	Description
Name	The unique name of the secret
Type	The kind of secret (e.g., ExternalSecret, Kubernetes Secret)
Status	The current synchronization state (e.g., Pending, Synced, Failed)
Scope	Indicates whether the secret is organizational or project-specific
Use case	The context for this secret (HuggingFace, S3, Database, Generic)
Assigned to	Lists the projects currently using the secret
Updated at	The timestamp of the last modification or synchronization
Actions	Available operations such as Edit Assignments or Delete

Add secrets#

To create a new secret, click the Add secret button on the main view. This opens the Add secret modal, where you can enter the details for the new secret.

The add secret modal.

In the modal, provide the following information:

Type: The type of secret (e.g., ExternalSecret)
External Secret (YAML): A valid Kubernetes-style YAML manifest defining the secret (see example below)
Usage Context: The context for this external secret
Assigned to: (Optional) Projects to immediately assign the secret to

Secrets must follow naming rules: lowercase letters, numbers, and dashes only (no spaces or special characters). The secret name defined in the YAML must be unique within the organization.

Example ExternalSecret manifest#

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: vault-backend-dev
  target:
    name: my-secret
    creationPolicy: Owner
  data:
    - secretKey: db-password
      remoteRef:
        key: prod/database
        property: password

Important

When creating an ExternalSecret, the referenced ClusterSecretStore must already exist in the cluster. Without it, the ExternalSecret cannot fetch values from the external provider. See the External Secrets Operator documentation for details on how to configure ClusterSecretStore for providers such as Vault, AWS, GCP, and Azure.

Secret scopes and types#

Organization-scoped vs. project-scoped secrets#

Secrets can be created with different scopes depending on your use case:

Organization-scoped secrets: Created at the organization level and can be assigned to multiple projects. These are ideal for shared credentials such as registry access tokens, or database credentials used across teams. Organization-scoped secrets can be reassigned to different projects as needed.
Project-scoped secrets: Created directly within a specific project and available only to that project. These secrets cannot be shared with other projects and are automatically tied to the project’s namespace. Project-scoped secrets are useful for credentials that are unique to a single application or workload.

When creating a secret from the main Secrets page, you can choose to create an organization-scoped secret and optionally assign it to one or more projects. When creating a secret from a project’s Secrets tab, the secret is automatically created as project-scoped and tied to that project.

Kubernetes Secrets#

In addition to ExternalSecrets, the platform also supports Kubernetes Secrets—native Kubernetes resources that store sensitive data directly in the cluster. Unlike ExternalSecrets, which fetch values from external providers, Kubernetes Secrets store the data within the cluster itself.

Kubernetes Secrets are useful when:

You don’t have an external secret provider configured
You need to store simple, non-rotated credentials
You want to quickly test or prototype without external dependencies

To create a Kubernetes Secret, select Kubernetes Secret as the type and provide a valid Kubernetes Secret manifest (in YAML format):

Create a kubernetes secret.

Example Kubernetes Secret manifest#

apiVersion: v1
kind: Secret
metadata:
  name: my-k8s-secret
type: Opaque
stringData:
  username: admin
  password: secret123

Assign secrets to projects#

Secrets can be securely shared across projects. Assigning a secret ensures it is synchronized to that project’s namespace in all relevant clusters.

To edit project assignments, click the actions menu (⋮) at the end of the secret’s row and select Edit assignment. This opens the Assign secret modal, which displays a list of available projects:

Assign a secret to projects.

The edit assignment modal.

To assign the secret, select the projects you want from the list.
To remove an assignment, deselect any projects that are already checked.

When finished, click Save changes to apply your updates.

Note

Project assignments are disabled while a secret is being updated or deleted. You must wait until the operation is complete before editing assignments.

Delete secrets#

To permanently delete a secret from the organization (and remove it from all assigned projects and synchronized clusters), open the actions menu (⋮) on the secret’s row and select Delete. This opens a confirmation modal where you must confirm the deletion. Click Delete to proceed.

The delete secret modal.

Deleting a secret permanently removes it from all projects and clusters.
This action cannot be undone.
Only platform administrators are allowed to delete secrets.

View secrets within a project#

In addition to the main Secrets page, you can also view secrets from within an individual project. Each project has its own Secrets tab, which lists only the secrets assigned to that project.

The secrets tab on a project page.

The project-level secrets view includes the following information:

Name: The name of the secret assigned to the project
Type: The kind of secret (e.g., ExternalSecret)
Status: The synchronization status for the secret in that project’s namespace
Use case: The context for this external secret
Updated at: The most recent time the secret was modified or synchronized

This view is useful for quickly confirming which secrets are available to workloads in a specific project without needing to navigate through the organization-wide Secrets page.