Managing Secret using Configuration File

Creating Secret objects using resource configuration file.

Before you begin

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

Create the Config file

You can create a Secret in a file first, in JSON or YAML format, and then create that object. The Secret resource contains two maps: data and stringData. The data field is used to store arbitrary data, encoded using base64. The stringData field is provided for convenience, and it allows you to provide Secret data as unencoded strings. The keys of data and stringData must consist of alphanumeric characters, -, _ or ..

For example, to store two strings in a Secret using the data field, convert the strings to base64 as follows:

  1. echo -n 'admin' | base64

The output is similar to:

  1. YWRtaW4=
  1. echo -n '1f2d1e2e67df' | base64

The output is similar to:

  1. MWYyZDFlMmU2N2Rm

Write a Secret config file that looks like this:

  1. apiVersion: v1
  2. kind: Secret
  3. metadata:
  4.   name: mysecret
  5. type: Opaque
  6. data:
  7.   username: YWRtaW4=
  8.   password: MWYyZDFlMmU2N2Rm

Note that the name of a Secret object must be a valid DNS subdomain name.

Note: The serialized JSON and YAML values of Secret data are encoded as base64 strings. Newlines are not valid within these strings and must be omitted. When using the base64 utility on Darwin/macOS, users should avoid using the -b option to split long lines. Conversely, Linux users should add the option -w 0 to base64 commands or the pipeline base64 | tr -d '\n' if the -w option is not available.

For certain scenarios, you may wish to use the stringData field instead. This field allows you to put a non-base64 encoded string directly into the Secret, and the string will be encoded for you when the Secret is created or updated.

A practical example of this might be where you are deploying an application that uses a Secret to store a configuration file, and you want to populate parts of that configuration file during your deployment process.

For example, if your application uses the following configuration file:

  1. apiUrl: "https://my.api.com/api/v1"
  2. username: "<user>"
  3. password: "<password>"

You could store this in a Secret using the following definition:

  1. apiVersion: v1
  2. kind: Secret
  3. metadata:
  4.   name: mysecret
  5. type: Opaque
  6. stringData:
  7.   config.yaml: |
  8.     apiUrl: "https://my.api.com/api/v1"
  9.     username: <user>
  10.     password: <password>

Create the Secret object

Now create the Secret using kubectl apply:

  1. kubectl apply -f ./secret.yaml

The output is similar to:

  1. secret/mysecret created

Check the Secret

The stringData field is a write-only convenience field. It is never output when retrieving Secrets. For example, if you run the following command:

  1. kubectl get secret mysecret -o yaml

The output is similar to:

  1. apiVersion: v1
  2. kind: Secret
  3. metadata:
  4.   creationTimestamp: 2018-11-15T20:40:59Z
  5.   name: mysecret
  6.   namespace: default
  7.   resourceVersion: "7225"
  8.   uid: c280ad2e-e916-11e8-98f2-025000000001
  9. type: Opaque
  10. data:
  11.   config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19

The commands kubectl get and kubectl describe avoid showing the contents of a Secret by default. This is to protect the Secret from being exposed accidentally to an onlooker, or from being stored in a terminal log. To check the actual content of the encoded data, please refer to decoding secret.

If a field, such as username, is specified in both data and stringData, the value from stringData is used. For example, the following Secret definition:

  1. apiVersion: v1
  2. kind: Secret
  3. metadata:
  4.   name: mysecret
  5. type: Opaque
  6. data:
  7.   username: YWRtaW4=
  8. stringData:
  9.   username: administrator

Results in the following Secret:

  1. apiVersion: v1
  2. kind: Secret
  3. metadata:
  4.   creationTimestamp: 2018-11-15T20:46:46Z
  5.   name: mysecret
  6.   namespace: default
  7.   resourceVersion: "7579"
  8.   uid: 91460ecb-e917-11e8-98f2-025000000001
  9. type: Opaque
  10. data:
  11.   username: YWRtaW5pc3RyYXRvcg==

Where YWRtaW5pc3RyYXRvcg== decodes to administrator.

Clean Up

To delete the Secret you have just created:

  1. kubectl delete secret db-user-pass

What’s next