Skip to main content
Secrets provide secure, centralized storage for sensitive data like credentials, API keys, certificates, and configuration values. Control Plane encrypts all secrets at rest and in transit, with fine-grained access control through policies ensuring only authorized workloads can access the data they need.

Encrypted Storage

All secrets are encrypted using industry-standard algorithms

Policy-Based Access

Fine-grained control over which workloads can access secrets

Multiple Injection Methods

Inject secrets as environment variables, mount as files, or use as pull secrets for private container registries

How Secrets Work

Secrets can be used in two primary ways: injected into workloads at runtime, or as pull secrets for accessing private container registries.

Injecting Secrets into Workloads

1

Create a Secret

Store your sensitive data in Control Plane using the Console, CLI, Terraform, or Pulumi. Choose the appropriate secret type for your use case.
2

Create an Identity

Create a workload identity that will be used to authenticate your workload and request access to secrets.
3

Grant Access with a Policy

Create a policy that grants the reveal permission on your secret to the workload identity.
4

Link Identity to Workload

Associate the identity with your workload so it inherits the policy permissions.
5

Reference the Secret

Use the cpln://secret/SECRET_NAME URI in your workload’s environment variables or volume mounts.
A workload identity must be granted the reveal permission on a secret to have its value injected at runtime.

Using Secrets as Pull Secrets

For pulling container images from private registries (Docker Hub, ECR, GCP Artifact Registry, etc.), you can attach registry credentials directly to your GVC as pull secrets. This approach doesn’t require identity or policy setup.
1

Create a Registry Secret

Create a Docker, ECR, or GCP secret with your registry credentials.
2

Add to GVC Pull Secrets

Add the secret to your GVC’s pullSecretLinks so all workloads in that GVC can pull from the private registry.
kind: gvc
name: my-gvc
spec:
  pullSecretLinks:
    - //secret/my-docker-registry
    - //secret/my-ecr-credentials
Pull secrets are configured at the GVC level and automatically available to all workloads within that GVC. No identity or policy configuration is needed for pull secrets.

Choosing the Right Secret Type

Cloud Provider Credentials

For authenticating with cloud services and pulling container images:

Application Secrets

For storing application configuration and credentials:

Certificates & Keys

For cryptographic operations and secure communication:

Best Practices

Choose the most specific secret type for your use case. For example, use AWS secrets for AWS credentials rather than storing them as Opaque. Specific types provide better validation and structured access.
Grant reveal permission only to identities that need it. Create separate policies for different secrets rather than granting broad access.
For API keys and tokens, environment variables are the simplest approach. Use volume mounts for certificates or when your application expects files.
Establish a rotation schedule for credentials. Update secrets in Control Plane and redeploy workloads to pick up new values.
Never commit secret values to version control. Use Terraform variables, Pulumi config secrets, or external secret management tools.
Use caution when handling sensitive values in IaC scripts. Best practices recommend using variables, encrypted state files, or external secret management rather than hard-coding sensitive values.

Using Secrets in Workloads

Once created, secrets can be injected into workloads as environment variables or mounted as files.
This guide assumes you already have a GVC, workload, and secret. If you haven’t created these yet, see Create a GVC, Create a Workload, and the secret type guides above.

Step 1: Create an Identity

1

Navigate to Identities

Navigate to Identities and click New, or click Create in the top-right corner and select Identity.
2

Select GVC

Ensure the correct GVC is selected in the GVC dropdown.
3

Enter name

Enter a Name (e.g., my-workload-identity).
4

Create the identity

Click Create.
1

Navigate to your workload

Navigate to your workload.
2

Open Identity settings

Click Identity in the left pane.
3

Select identity

Select the identity you created (e.g., my-workload-identity).
4

Save changes

Click Save.

Step 3: Create a Policy for Secret Access

1

Navigate to Policies

Navigate to Policies and click New, or click Create in the top-right corner and select Policy.
2

Enter name

Enter a Name (e.g., workload-secret-access).
3

Configure target

Click Target in the left pane. Under Kind, select Secret.
4

Add secret items

Click Items in the left pane. Click Add and select the secret you want to grant access to.
5

Add binding

Click Bindings in the left pane. Click Add.
6

Configure permissions

In the Permissions tab, select reveal. In the Identities tab, select the identity linked to your workload. Click OK.
7

Create the policy

Click Create.

Step 4: Inject Secret into Workload

Option 1: Environment Variables
1

Navigate to your workload

Navigate to your workload.
2

Open Env Vars

Click Containers in the left pane, then select the Env Vars tab.
3

Add environment variable

Click Add. Enter the variable Name (e.g., MY_SECRET).
4

Select secret

In the Value dropdown, change Literal Value to CPLN Secret. In the dropdown next to it, find and select your secret by name.
5

Update workload

Click Update.
Option 2: Volume Mount
1

Navigate to your workload

Navigate to your workload.
2

Open Volumes

Click Containers in the left pane, then select the Volumes tab.
3

Add volume

Click Add. Ensure CPLN Secret is selected for the URI type.
4

Configure mount

Select the secret from the dropdown by name. Enter the Path where the secret will be mounted (e.g., /secrets/my-secret.txt).
5

Update workload

Click Update.

Secret Reference Formats

When referencing secrets, use the cpln://secret/ URI format:
FormatDescriptionExample
cpln://secret/SECRET_NAMEReference entire secret payloadcpln://secret/my-secret
cpln://secret/SECRET_NAME.KEYReference specific key in dictionary/structured secretscpln://secret/my-config.DB_PASSWORD
The mount behavior varies by secret type:
  • Opaque: The payload is mounted as a file at the specified path
  • Dictionary and other structured secrets: A directory is created containing files for each key/property
  • Docker, Azure SDK, and GCP: The secret is mounted as a file named ___cpln___.secret in the specified directory
For more details, see the Workload Volumes Reference.

Next Steps