ManagementCore API
Secrets

As in Kubernetes, Octelium has a dedicated Secret type for storing sensitive data such as API tokens and passwords, which can be used and referenced by other Cluster resources via the Secret's name to avoid storing sensitive data along with other Cluster configurations that can be stored in Git repositories, for example.

Secrets are used by various other Cluster resources such as Services, and IdentityProviders. For example, Services use Secrets to provide secret-less access. You can read more about secret-less access here.

Creating a Secret

You can create a Secret via the octeliumctl create secret command using one of the following ways:

Value via Prompt

You can insert your Secret value directly via prompt as follows:

octeliumctl create secret apikey1
Enter the secret: <SECRET_VALUE>

From File

You can also create a Secret from the content of a file as follows:

octeliumctl create secret aws-ssh-pk --file /PATH/TO/SSH/PRIVATE_KEY

TLS Certificate

You can create a Secret from a TLS certificate using the PEM file paths of the certificate chain and its corresponding private key. Such Secrets are typically useful for use cases like a Service using the Secret as a client certificate to connect to the Service's upstream, which is protected by mTLS (read more here).

octeliumctl create secret mtls-k8s-01 --cert /PATH/TO/CERTIFICATE_CHAIN.PEM --cert-key /PATH/TO/CERTIFICATE_PRIVATE_KEY.PEM

Listing Secrets

You can list the Cluster's Secrets as follows:

octeliumctl get secret
# Or simply
octeliumctl get sec
# Show a certain Secret
octeliumctl get sec <NAME>
NOTE

It is important to understand that the Cluster does not currently expose the Secret data itself via the API, and consequently the octeliumctl CLI, but only keeps the Secret's actual sensitive value internally. In other words, the octeliumctl get secret command only exposes the Secret resource without its data field that actually contains the Secret's sensitive data.

Deleting a Secret

You can also delete a Secret as follows:

octeliumctl delete secret <SECRET_NAME>

Using the Declarative Approach

You can actually use octeliumctl apply with Secrets as well, by using the --include-secret flag. This assumes that you can securely store your Secrets in YAML files as opposed to just pushing them to git repositories like normal resources. Here is an example:

1
kind: Secret
2
metadata:
3
name: my-secret
4
spec: {}
5
data:
6
value: TOP_SECRET_VALUE

And you can simply apply your changes as follows:

octeliumctl apply --include-secret /PATH/TO/SECRETS

Secret Storage

Just like in Kubernetes, the Octelium Cluster, by default, stores a Secret's data in plaintext like any other Cluster resource. However, Octelium gives you the ability to develop your own encryption-at-rest method according to your requirements by providing a gRPC interface (see here) where you can intercept Secret Create/Get/Update/List/Delete operations to the ResourceServer and store the Secret in your secret store according to your specific requirements.

NOTE

Octelium provides a commercial, scalable Secret encryption-at-rest management that integrates with AWS KMS, Google Cloud KMS, Azure Vault Key, Hashicorp Vault, and other secret managers and vaults on-demand. You can see the list of our offerings here.

© 2025 octelium.comOctelium Labs, LLCAll rights reserved
Octelium and Octelium logo are trademarks of Octelium Labs, LLC.
WireGuard is a registered trademark of Jason A. Donenfeld