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 apikey1Enter 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 simplyocteliumctl get sec# Show a certain Secretocteliumctl get sec <NAME>
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:
1kind: Secret2metadata:3name: my-secret4spec: {}5data:6value: 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.
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.