Konduktor makes it easy to manage sensitive credentials like API keys, SSH keys, cloud credentials, and environment variables through a built-in secret management system. Secrets are stored as Kubernetes Secrets and are automatically injected into the workloads of the user who created them. Some secrets (kind=env) can be exposed inside the workload as environment variables, while others (kind=default) are mounted as files or directories.
Creating Secrets
To create a secret, use the konduktor secret create command shown below. If a Konduktor secret with the same name already exists under your ownership, the new data will be merged with the existing contents rather than replacing it. This allows a one to many relationship between Konduktor secret names and secrets data (basically key:value pairs). If you need to replace a Konduktor secret entirely, delete the existing Konduktor secret first, then create a new one. Different users in the same cluster can create secrets with the same name without conflict as each user’s secrets are functionally isolated.
Where valid [FLAGS] include:
You can choose from several secret kinds, depending on how you want the secret to be injected into your workload:
1. kind=default
Use this kind to create general-purpose secrets that will be mounted directly into your pods as files or directories. Any of the three source flags are acceptable. Excluding the --kind flag will default to --kind=default.
They will be accessible within the workload at $KONDUKTOR_DEFAULT_SECRETS/<SECRET_NAME>/. Here is an example snippet of a workload yaml accessing the various default secrets:
2. kind=git-ssh
Use this kind to store an SSH private key for accessing Git repositories via SSH. You must use --from-file. A user is limited to only one git-ssh secret.
This secret will be automatically mounted into workloads and configured via the environment variable GIT_SSH_COMMAND, allowing secure Git operations. Here is an example snippet of a workload yaml:
3. kind=env
Use this kind to store environment variables directly. Environment secrets are automatically injected into job containers as environment variables. You must use --inline to define key-value pairs directly in the CLI.
Here is an example snippet of a workload yaml utilizing the automatic env secret mounting:
Viewing Secrets
To view your own secrets:
To view secrets of all users in the cluster:
Deleting Secrets
To delete a secret, use the secret name. Users can only delete the secrets they created.
There is a known issue where users who submit jobs from two different machines cannot manage/use the same set of secrets across workstations since ownership of the secret is determined currently by username + device MAC address. We are currently working to address this, but as a mitigation, users can recreate the same secrets on different workstations to get the same benefit.
Konduktor secrets are backed by Kubernetes secrets and as such have a size limit of 1MB. In practice, we recommend users only use secrets that are around 1K or less to prevent unexpected issues with secrets mounting
