Secrets Overview

secrets external-secrets vault aws google cloud azure AMD Resource Manager

Secrets Overview#

Secrets provide a centralized and secure mechanism for storing, retrieving, and distributing sensitive data—such as API keys, database credentials, and access tokens—across projects, ensuring workloads can access them safely when needed.

The platform supports two types of secrets:

  • External Secrets: Fetch sensitive data from external secret providers such as HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault. This approach keeps credentials in a secure backend and synchronizes them to clusters only when needed. An External Secret is a Custom Resource Definition (CRD) which is a way to extend Kubernetes with new types of resources beyond the built-in ones (like Secret), allowing you to define and manage custom objects that behave like native Kubernetes resources.

  • Kubernetes Secrets: Native Kubernetes resources that store sensitive data directly within the cluster. These are useful for simple use cases or when an external provider is not available.

For detailed instructions on managing secrets, see the Manage secrets guide.

You can manage secrets from the dedicated Secrets page or at the project level through the Secrets tab on each project’s page.

What is a secret?#

A secret is a piece of sensitive information, such as an API key, database credential, or token, that workloads in your projects need to operate. Secrets are securely stored and synchronized to clusters.

Secrets can be created with different scopes:

  • Organization-scoped secrets: Created at the organization level and can be assigned to multiple projects. These secrets can be shared across teams and reassigned as needed.

  • Project-scoped secrets: Created directly within a specific project and available only to that project. These secrets are automatically tied to the project’s namespace and cannot be shared.

AMD Resource Manager ensures that secrets are propagated correctly and remain in sync with their target clusters and projects.

How synchronization works#

Secrets are synchronized to Kubernetes clusters based on their type:

For External Secrets:

  • The platform creates an ExternalSecret CRD in the project’s namespace.

  • The ExternalSecret fetches values from the configured backend provider (e.g., Vault, AWS).

  • The External Secrets Operator then creates a native Kubernetes Secret with the fetched data.

  • Workloads in that namespace can reference the secret just like any other Kubernetes secret.

This ensures secret data remains in the secure backend and is only exposed to workloads at runtime.

For Kubernetes Secrets:

  • The platform creates a native Kubernetes Secret directly in the project’s namespace.

  • Workloads can immediately reference the secret without requiring external dependencies.

Access control#

  • Platform admins can create organization secrets, assign them to projects, and manage all project secrets.

  • Team members can view and use secrets in their assigned projects but cannot create or modify organization secrets.

Secret statuses#

Secrets and their project assignments can move through the following states:

  • Unassigned: The secret exists but has not been assigned to any projects. Displayed as --- in the UI.

  • Pending: The secret is being created or updated, and synchronization with assigned projects is in progress.

  • Synced: The secret has been successfully synchronized with all assigned projects.

  • PartiallySynced: The secret has synchronized with some projects but not all.

  • SyncedError: Synchronization finished, but one or more projects reported errors.

  • Failed: A critical error prevented the secret from being created, updated, or synchronized.

  • Deleting: The secret is in the process of being removed from all projects.

  • DeleteFailed: An error occurred while attempting to remove the secret from one or more projects.