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. They can be exposed inside the workload as environment variables, or mounted as text files or directories.

​
Creating Secrets

To create a secret, use the konduktor secret create command shown below. If a secret with the same name already exists under your ownership, the new data will be merged with the existing contents rather than replacing it. If you need to replace a secret entirely, delete the existing 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 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"

  echo "Accessing directory-based secret"
  ls "$KONDUKTOR_DEFAULT_SECRETS/my-default-directory"

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

​
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 git@github.com:mygithubaccount/My-App.git

​
3. kind=env

Use this kind to store environment variables directly. Environment secrets are automatically injected as environment variables. You must use --inline to define key-value pairs directly on 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>