Managing Secrets

Konduktor simplifies Kubernetes secret management with a CLI that makes secrets easily accessible within your workloads.

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.

konduktor secret create [FLAGS] <SECRET_NAME>

Where valid [FLAGS] include:

--kind=<KIND> # see below for supported secret types

# mutually exclusive source flags:
--from-file=<FILE_PATH>
--from-directory=<DIRECTORY_PATH>
--inline KEY=VALUE

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.

$ konduktor secret create --kind=default --from-file=./tests/secrets/secret-file.txt my-default-file
$ konduktor secret create --kind=default --from-directory=./tests/secrets my-default-directory
$ konduktor secret create --kind=default --inline FOO=bar my-default-inline

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:

name: test-default-secrets

run: |
  echo "Accessing file-based secret"
  ls "$KONDUKTOR_DEFAULT_SECRETS/my-default-file"
  cat "$KONDUKTOR_DEFAULT_SECRETS/my-default-file/secret-file.txt"
  
  # Note that directory name is preserved and whole directory (including subdirectories) is copied
  echo "Accessing directory-based secret"
  ls "$KONDUKTOR_DEFAULT_SECRETS/my-default-directory"
  ls "$KONDUKTOR_DEFAULT_SECRETS/my-default-directory/secrets/"
  cat "$KONDUKTOR_DEFAULT_SECRETS/my-default-directory/secrets/secret-file.txt"

  echo "Accessing inline secret"
  ls "$KONDUKTOR_DEFAULT_SECRETS/my-default-inline"
  cat "$KONDUKTOR_DEFAULT_SECRETS/my-default-inline/FOO"

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.

$ konduktor secret create --kind=git-ssh --from-file=~/.ssh/id_rsa my-ssh-name

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:

name: test-gitssh-secret

run: |
  git clone [e-mail]:mygithubaccount/My-App.git

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.

$ konduktor secret create --kind=env --inline FOO=bar my-env-name

Here is an example snippet of a workload yaml utilizing the automatic env secret mounting:

name: test-env-secret

run: |
  echo "My FOO is $FOO" # results in "My FOO is bar"

Viewing Secrets

To view your own secrets:

$ konduktor secret list

To view secrets of all users in the cluster:

$ konduktor secret list --all-users
$ konduktor secret list -u

Deleting Secrets

To delete a secret, use the secret name. Users can only delete the secrets they created.

$ konduktor secret delete <SECRET_NAME>

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