Overview
Secrets are the fundamental resource in Polystack Key Manager. Each secret stores an encrypted payload with type and algorithm metadata. Secrets are project-scoped — they are visible only to users within the project that created them unless shared via ACL. Secrets are referenced by UUID and payloads are never returned in API responses outside of an explicit retrieve operation.Prerequisites
- An active Polystack account with appropriate permissions
- Access to the Polystack Dashboard or CLI configured with credentials
- API credentials sourced (
source openrc.sh)
Project Scope — All secrets created in Key Manager belong to the project
selected at the time of creation. Users in other projects cannot see or access
your secrets unless you explicitly grant access through an ACL. If you switch
projects in the Dashboard, you will see a different set of secrets.
Secret Types
Polystack Key Manager supports six secret types. The type you select determines which algorithm, key length, and encryption mode options are available.Create a Secret
- Dashboard
- CLI
Create secrets through the Polystack Dashboard with a form that adapts
based on the selected secret type.
1
Navigate to Key Manager
Navigate to Key Manager > Secrets in the sidebar.Click Create Secret in the upper-right corner.
2
Enter the secret name
Enter a descriptive Name for your secret. This is a required field and serves
as a human-readable identifier (e.g.,
db-root-password, app-tls-private-key).3
Select the secret type
Choose the Secret Type from the dropdown. This selection controls which
additional fields appear in the form:
4
Configure algorithm options (if applicable)
For secret types that support cryptographic metadata, configure the following
fields. These fields appear dynamically based on your secret type selection:Algorithm — Select the cryptographic algorithm:
Bit Length — Select the key size (appears after algorithm selection):
Mode — Select the block cipher mode (symmetric keys only):
5
Select a secret store backend (optional)
If your platform has multiple secret store backends configured, a Secret Store
Backend dropdown appears. Select which backend should store this secret.The default backend is pre-selected and marked with (Default).
This field only appears when the administrator has configured multiple
secret store backends. Most deployments use a single backend.
6
Set an expiration date (optional)
Use the Expiration date-time picker to set an optional expiration date for
the secret. After this date, the secret is no longer usable.
7
Enter the payload
Enter the secret value in the Payload text area. The form displays a
format hint based on the selected secret type:
The payload field is optional at creation time. You can create a secret
without a payload and add it later via the API. However, most use cases
require providing the payload during creation.
8
Select payload content type
If you entered a payload, select the Payload Content Type:
9
Create the secret
Click Confirm to create the secret. It appears in the Secrets list with
status Active.
Secret appears in the Secrets list with its UUID and Active status.
Retrieve a Secret
- Dashboard
- CLI
1
View secret metadata
Navigate to Project > Key Manager > Secrets. Click the secret name
to open the detail page.The detail page shows:
2
Retrieve the payload
Delete a Secret
- Dashboard
- CLI
1
Select secrets to delete
Navigate to Project > Key Manager > Secrets. Select one or more
secrets using the checkboxes, then click Delete in the actions menu.Alternatively, click the More menu on a single secret row and
select Delete Secret.
2
Confirm deletion
Confirm the deletion in the dialog. This action is permanent.
Deleting a secret is irreversible. If the secret is referenced by
containers, Load Balancer listeners, or volume encryption, those
references will break immediately. Update all references before deleting.
Project Scope and Access
Secrets in Key Manager are project-scoped by default:Secret Type Reference
Opaque
Opaque
Use case: Store any arbitrary data — API keys, database passwords, configuration
values, OAuth tokens, or binary blobs.No algorithm or key length metadata is required. This is the most flexible type
and the default selection.
CLI example
Symmetric
Symmetric
Use case: Store symmetric encryption keys for AES, DES, or 3DES encryption.
Used for volume encryption, object storage encryption, and application-level encryption.
CLI example — AES-256 GCM
Public Key
Public Key
Use case: Store RSA, DSA, or EC public keys for key pair management,
signature verification, or encryption.
CLI example — RSA 4096 public key
Private Key
Private Key
Use case: Store RSA, DSA, or EC private keys for TLS, SSH, or code signing.
Always pair with a corresponding public key or certificate.
CLI example — RSA 4096 private key
Certificate
Certificate
Use case: Store X.509 TLS/SSL certificates for HTTPS termination,
mTLS authentication, or certificate chain management.
CLI example — TLS certificate
Passphrase
Passphrase
Use case: Store passwords, passphrases, PINs, or other human-readable
credential strings. No algorithm metadata is required.
CLI example
Next Steps
Containers
Bundle secrets into named containers for TLS and key pair management
Certificates
Store and manage TLS certificates using Key Manager
Access Control (ACL)
Share secrets across projects with fine-grained access control
Troubleshooting
Resolve 403 errors, payload retrieval failures, and expired secret issues
