Please visit these pages for more details about Secrets:
https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/
https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kubectl/

Secrets allows creating data objects that can be consumed by Pods at runtime.
The data in Secrets is stored as key-value entries:

• Key: is a string value formed by alphanumeric, dot (.), dash (-), and underscore (_) characters.
  
  
• Value: is a base64-encoded string value.
  To encode a text into a base64 string:
  $ echo -n 'value1' | base64 dmFsdWUx
  The -n flag ensures that the generated output doesn't have an extra newline character at the end of the text. This is to avoid that the extra newline character gets encoded along with the text.
  
  To decode a base64 data:
  $ echo 'dmFsdWUx' | base64 --decode value1
  

The key and the value, in the Secrets, are separated with a colon (key:value).

The name of the Secrets must be a valid DNS subdomain name.

The data stored in a Secrets can be consumed in a container in one the following ways:

• Environment variables.
  
  
• Command-line arguments of the container command.
  
  
• Files in volumes.
  
  
• Custom code (read the Secrets directly from the Kubernetes API).
  
  

Note:
If you update a Secrets that was already posted to the Kubernetes API server, then containers that were already created will be able to leverage the new data only if it was injected as files in a volume. Secrets data injected as environment variables won't be updated in a running container.

The data of the Secrets can be specified using:

• generic --from-literal:
  Specify a key and literal value to insert in the Secret.
  You need to escape the special characters $, \, *, =, and ! (otherwise they will be interpreted by the shell).
  One way to escape the special characters is to enclose the value within single quotes (').
  
  Create the Secrets:
  $ kubectl create secret generic secretfromliteral --from-literal="key1=value1" --from-literal=key2='value2' secret/secretfromliteral created
  Check the Secret:
  $ kubectl get secret secretfromliteral NAME TYPE DATA AGE secretfromliteral Opaque 2 9m5s
  Describe the Secret:
  $ kubectl describe secret secretfromliteral Name: secretfromliteral Namespace: default Labels: <none> Annotations: <none> Type: Opaque Data ==== key1: 6 bytes key2: 6 bytes
  View the YAML file of the Secret:
  $ kubectl get secrets secretfromliteral -o json apiVersion: v1 data: key1: dmFsdWUx key2: dmFsdWUy kind: Secret metadata: name: secretfromliteral namespace: default type: Opaque { "apiVersion": "v1", "data": { "key1": "dmFsdWUx", "key2": "dmFsdWUy" }, "kind": "Secret", "metadata": { "name": "secretfromliteral", "namespace": "default", }, "type": "Opaque" }
  The manifest file of the Secrets is pretty simple.
  It contains the fields apiVersion, kind, and metadata.
  It also contain the data field that contains the keys-values of the Secrets.
  
  To decode the Secret of a specific key, you need to decode its base64 data:
  $ kubectl get secrets secretfromliteral -o jsonpath='{.data.key1}' | base64 --decode - value1 $ kubectl get secrets secretfromliteral -o jsonpath='{.data.key2}' | base64 --decode - value2 $ echo 'dmFsdWUy' | base64 --decode value1
  
• generic --from-file:
  Specify a file path (--from-file="/home/nhabti/secrets/file1.txt"), in which case the file base name will be used as the Secret key.
  
  Or optionally with a key and file path (--from-file="mykey1=/home/nhabti/secrets/file1.txt"), in which case the given key will be used as the Secret key.
  
  Specifying a directory (--from-file="/home/nhabti/secretsdir/") will iterate each named file in the directory and create a new entry for each file whose base name is a valid Secret key.
  
  The path to the file (or directory) can be an absolute path or relative to the location from where the "kubectl create secret" is executed.
  
  The content of the file can be anything.
  You don't have to escape special characters in the text that you put in the file.
  
  Create sample files:
  $ echo -n 'value1' > "/home/nhabti/secrets/file1.txt" $ echo -n 'value2' > "/home/nhabti/secrets/file2.txt"
  
  • Create the Secret (from file without a key):
    $ kubectl create secret generic secretfromfile1 --from-file="/home/nhabti/secrets/file1.txt" --from-file="/home/nhabti/secrets/file2.txt" secret/secretfromfile1 created
    View the Secrets (notice that the content of the file is indented properly):
    $ kubectl get secret secretfromfile1 -o yaml apiVersion: v1 data: file1.txt: dmFsdWUx # note that the name of the key is file1.txt file2.txt: dmFsdWUy # note that the name of the key is file2.txt kind: Secret metadata: name: secretfromfile1 namespace: default type: Opaque
    
  • Create the Secrets (from file with a key):
    $ kubectl create secret generic secretfromfile2 --from-file="mykey1=/home/nhabti/secrets/file1.txt" --from-file="mykey2=/home/nhabti/secrets/file2.txt" secret/secretfromfile2 created
    View the Secrets (notice that the content of the file is indented properly):
    $ kubectl get secret secretfromfile2 -o yaml apiVersion: v1 data: mykey1: dmFsdWUx # note that the name of the key is mykey1 mykey2: dmFsdWUy # note that the name of the key is mykey2 kind: Secret metadata: name: secretfromfile2 namespace: default type: Opaque
    
  • Create the Secrets (from a directory):
    $ kubectl create secret generic secretfromdirectory --from-file="/home/nhabti/secrets/" secret/secretfromdirectory created
    View the Secrets (notice that the content of the file is indented properly):
    $ kubectl get secret secretfromdirectory -o yaml apiVersion: v1 data: file1.txt: dmFsdWUx # note that the name of the key is file1.txt file2.txt: dmFsdWUy # note that the name of the key is file2.txt kind: Secret metadata: name: secretfromfile1 namespace: default type: Opaque<
  
  
• --from-env-file:
  Specify the path to a file (--from-file="/home/nhabti/secrets/file1.properties") to read lines of key=val pairs to insert in the Secrets.
  
  Create simple files:
  $ vi "/home/nhabti/secrets/file1.properties" key1=value1 key2=value2
  Create the Secrets:
  $ kubectl create secret generic secretfromenvfile --from-env-file="/home/nhabti/secrets/file1.properties" secret/secretfromenvfile created
  View the Secrets (notice that the content of the file is indented properly):
  $ kubectl get secret secretfromenvfile -o yaml apiVersion: v1 data: key1: dmFsdWUx key2: dmFsdWUy kind: Secret metadata: name: secretfromenvfile namespace: default type: Opaque

Regular Manifest yaml file that defines a ConfigMag with simple key-value entries:
$ vi secretkeyvalue.yaml apiVersion: v1 kind: Secret metadata: name: secretkeyvalue namespace: default data: key1: dmFsdWUx key2: dmFsdWUy
Note that the values of the keys are base64 encoded strings.

To apply the file:
$ kubectl apply -f secretkeyvalue.yaml secret/secretkeyvalue created

If you have created a Secret using the manifest YAML file, then to change that Secret you only need to adjust the YAML file and run the command kubectl apply -f SECRET-YAML-FILE-PATH

You can also use the command kubectl edit secret SECRET-NAME to edit a Secret. The command will open the Secret in your default text editor. You do your changes and save that. Once you exit the editor, your changes will be submitted to API Server.

For example to view and edit the Secret "secretkeyvalue":
$ kubectl edit secret secretkeyvalue # Please edit the object below. # Lines beginning with a '#' will be ignored, and an empty file will abort the edit. # If an error occurs while saving this file will be reopened with the relevant failures. # apiVersion: v1 data: key1: dmFsdWUx key2: dmFsdWUy kind: Secret metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"key1":"dmFsdWUx","key2":"dmFsdWUy"},"kind":"Secret","metadata":{"annotations":{},"name":"secretkeyvalue","namespace":"default"}} creationTimestamp: "2021-06-06T04:26:46Z" name: secretkeyvalue namespace: default resourceVersion: "2053746" selfLink: /api/v1/namespaces/default/secrets/secretkeyvalue uid: a35d4344-88bc-4e29-82e9-13850b923a1e type: Opaque secret/secretkeyvalue edited

In a Pod YAML file, You can reference the entries of the Secrets directly in the "spec.containers.env" field. The environment variables will be set as any other regular Linux environment variables. You can check them using the env command directly from inside the container.

Note that if you start the Pod and later you change the Secrets, then these changes won't be reflected in the container unless you recreate the Pod.

• Let's use the ConfiMap "secretkeyvalue" (see above) with the Pod "hello-busybox-secrets":
  $ vi hello-busybox-secrets-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-secrets spec: containers: - name: hello-busybox-secrets image: busybox:latest tty: true # (TeleTYpewriter) allocates a TTY / terminal console on the container stdin: true # Keeps stdin open on the container env: - name: mykey1 valueFrom: secretKeyRef: name: secretkeyvalue key: key1 - name: mykey2 valueFrom: secretKeyRef: name: secretkeyvalue key: key2
  Note:
  You can give the environment variable a different name than the Secrets key name (i.e. name: mykey1).
  
  Apply the Pod:
  $ kubectl apply -f hello-busybox-secrets-pod.yaml pod/hello-busybox-secrets created
  Check the environment variables:
  $ kubectl exec hello-busybox-secrets -- env | grep key mykey1=value1 mykey2=value2
  Note that the secrets are clear text!
  
  
• Instead of referencing individual entries of the ConfiMap, you can use the "spec.containers.envFrom" field to reference all entries of the ConfiMap:
  $ vi hello-busybox-secrets-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-secrets spec: containers: - name: hello-busybox-secrets image: busybox:latest tty: true stdin: true envFrom: - secretRef: name: secretkeyvalue
  Apply the Pod:
  $ kubectl apply -f hello-busybox-secrets-pod.yaml pod/hello-busybox-secrets created
  Check the environment variables:
  $ kubectl exec hello-busybox-secrets -- env | grep key key1=value1 key2=value2

Secrets can also be referenced using volumes.

Each entry of the Secrets will be referenced as a separate file in the volume.

The changes to the Secrets will be reflect directly in the volumes.

The Secrets is defined as a volume (spec.volumes) and mounted to the container (spec.containers.volumeMounts).

• In the following example, the .spec.volumes field creates a volume (named secretkeyvalue) from the "secretkeyvalue" Secrets.
  The .spec.containers.volumeMounts field mounts the volume (secretkeyvalue) into the container (under /tmp/secretkeyvalue).
  The volume will be populated with files where the file name is the key of the Secrets (key1, key2) and the content of the file is the value of the key (value1, value2).
  
  $ vi hello-busybox-secrets-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-secrets spec: containers: - name: hello-busybox-secrets image: busybox:latest tty: true stdin: true volumeMounts: - name: secretkeyvalue mountPath: /tmp/secretkeyvalue volumes: - name: secretkeyvalue secret: secretName: secretkeyvalue
  Apply the Pod:
  $ kubectl apply -f hello-busybox-secrets-pod.yaml pod/hello-busybox-secrets created
  Check the files in the volume (notice two files are created: key1, key2):
  $ kubectl exec hello-busybox-secrets -- ls /tmp/secretkeyvalue key1 key2
  Check the content of the files:
  $ kubectl exec hello-busybox-secrets -- cat /tmp/secretkeyvalue/key1 value1
  
• You can also decide what entries of the ConfigMag can be mounted (you can also decide the name of file in the volume "path"):
  $ vi hello-busybox-secrets-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-secrets spec: containers: - name: hello-busybox-secrets image: busybox:latest tty: true stdin: true volumeMounts: - name: secretkeyvalue mountPath: /tmp/secretkeyvalue volumes: - name: secretkeyvalue secret: secretName: secretkeyvalue items: - key: key1 path: key1path
  Apply the Pod:
  $ kubectl apply -f hello-busybox-secrets-pod.yaml pod/hello-busybox-secrets created
  Check the files in the volume (notice the "key1path" file was created):
  $ kubectl exec hello-busybox-secrets -- ls /tmp/secretkeyvalue key1path
  Check the content of the files:
  $ kubectl exec hello-busybox-secrets -- cat /tmp/secretkeyvalue/key1path value1

You can use the data of the Secrets to set the command or arguments in the container.
You use the following syntax to reference the environment variable: $(ENV_VAR_NAME).

As previously mentioned, changes to the Secrets won't be reflect for the environment variables already set.

Not the best example, but this should give you an idea about using the secrets in the container's command:
$ vi hello-busybox-secrets-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-secrets spec: containers: - name: hello-busybox-secrets image: busybox:latest command: ['sh', '-c', 'echo "mykey1:$(mykey1) | mykey2:$(mykey2)"; sleep 300;'] env: - name: mykey1 valueFrom: secretKeyRef: name: secretkeyvalue key: key1 - name: mykey2 valueFrom: secretKeyRef: name: secretkeyvalue key: key2
Apply the Pod:
$ kubectl apply -f hello-busybox-secrets-pod.yaml pod/hello-busybox-secrets created
Check the logs of the Pod:
$ kubectl logs hello-busybox-secrets mykey1:value1 | mykey2:value2

To delete a Secret: using manifest file (kubectl delete):
$ kubectl delete -f secretkeyvalue.yaml secret "secretkeyvalue" deleted
To delete a Secret using its name:
$ kubectl delete secret secretkeyvalue secret "secretkeyvalue" deleted