Managing Secrets using 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. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. 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 Secret
You can define the Secret
object in a manifest 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
the same data as unencoded strings.
The keys of data
and stringData
must consist of alphanumeric characters,
-
, _
or .
.
The following example stores two strings in a Secret using the data
field.
Convert the strings to base64:
echo -n 'admin' | base64 echo -n '1f2d1e2e67df' | base64
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 thebase64
utility on Darwin/macOS, users should avoid using the-b
option to split long lines. Conversely, Linux users should add the option-w 0
tobase64
commands or the pipelinebase64 | tr -d '\n'
if the-w
option is not available.The output is similar to:
YWRtaW4= MWYyZDFlMmU2N2Rm
Create the manifest:
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm
Note that the name of a Secret object must be a valid DNS subdomain name.
Create the Secret using
kubectl apply
:kubectl apply -f ./secret.yaml
The output is similar to:
secret/mysecret created
To verify that the Secret was created and to decode the Secret data, refer to Managing Secrets using kubectl.
Specify unencoded data when creating a Secret
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:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
You could store this in a Secret using the following definition:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
Note:
ThestringData
field for a Secret does not work well with server-side apply.When you retrieve the Secret data, the command returns the encoded values,
and not the plaintext values you provided in stringData
.
For example, if you run the following command:
kubectl get secret mysecret -o yaml
The output is similar to:
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
Specify both data
and stringData
If you specify a field in both data
and stringData
, the value from stringData
is used.
For example, if you define the following Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
Note:
ThestringData
field for a Secret does not work well with server-side apply.The Secret
object is created as follows:
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
YWRtaW5pc3RyYXRvcg==
decodes to administrator
.
Edit a Secret
To edit the data in the Secret you created using a manifest, modify the data
or stringData
field in your manifest and apply the file to your
cluster. You can edit an existing Secret
object unless it is
immutable.
For example, if you want to change the password from the previous example to
birdsarentreal
, do the following:
Encode the new password string:
echo -n 'birdsarentreal' | base64
The output is similar to:
YmlyZHNhcmVudHJlYWw=
Update the
data
field with your new password string:apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: YmlyZHNhcmVudHJlYWw=
Apply the manifest to your cluster:
kubectl apply -f ./secret.yaml
The output is similar to:
secret/mysecret configured
Kubernetes updates the existing Secret
object. In detail, the kubectl
tool
notices that there is an existing Secret
object with the same name. kubectl
fetches the existing object, plans changes to it, and submits the changed
Secret
object to your cluster control plane.
If you specified kubectl apply --server-side
instead, kubectl
uses
Server Side Apply instead.
Clean up
To delete the Secret you have created:
kubectl delete secret mysecret
What's next
- Read more about the Secret concept
- Learn how to manage Secrets using kubectl
- Learn how to manage Secrets using kustomize