ConfigMaps and Secrets

while deploying and application, we may need to pass such rumtime parameters like configuration details, permissions, passwords, token,etc.
ConfigMap API : use to pass configuration bit
Secret API : use to pass sentive data.

ConfigMaps

allow us to decouple the configuration details from the container image.
we pass configuration data as key-value pairs.
configuration data consummed by Pods or any ther system compomnets and controllers, in the form of environment variables, sets of commands and arguments, or volumes.
We can create ConfigMaps from literal values, from configuration files, from one or more file or directories.
A ConfigMap can be created with the kubectl create command
We can display its details using the kubectl get command.
Create teh config Map exaample.

$ kubectl create configmap --help
...
  # Create a new configmap named my-config based on folder bar
  kubectl create configmap my-config --from-file=path/to/bar

  # Create a new configmap named my-config with specified keys instead of file basenames on disk
  kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt
--from-file=key2=/path/to/bar/file2.txt

  # Create a new configmap named my-config with key1=config1 and key2=config2
  kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

  # Create a new configmap named my-config from the key=value pairs in the file
  kubectl create configmap my-config --from-file=path/to/bar

  # Create a new configmap named my-config from an env file
  kubectl create configmap my-config --from-env-file=path/to/bar.env
  ...

let's execute it for real

$ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2 --dry-run -o yaml
apiVersion: v1
data:
  key1: value1
  key2: value2
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: my-config

let's execute it for real - really.

$ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
configmap/my-config created

show config

$ kubectl get configmap my-config
NAME        DATA   AGE
my-config   2      26s

show config in yaml

$ kubectl get configmap my-config -o yaml
apiVersion: v1
data:
  key1: value1
  key2: value2
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-01T01:54:48Z"
  name: my-config
  namespace: default
  resourceVersion: "125055"
  selfLink: /api/v1/namespaces/default/configmaps/my-config
  uid: 4ee24a1b-250e-4af5-b03c-a1e444b93c9b

Create a ConfigMap from a Configuraiton File

generate it via kubectl

$ kubectl create configmap customer1 --from-literal=TEXT1=Customer1_Company --from-literal=TEXT2="Welcomes You" --from-literal=COMPANY="Customer1 Company Technology Pct. Ltd." --dry-run -o yaml > customer1-configmap.yaml

show the file output

$ cat customer1-configmap.yaml
apiVersion: v1
data:
  COMPANY: Customer1 Company Technology Pct. Ltd.
  TEXT1: Customer1_Company
  TEXT2: Welcomes You
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: customer1

create configmaps from file

$ kubectl create -f customer1-configmap.yaml
configmap/customer1 created

show details

$ kubectl get configmaps customer1
NAME        DATA   AGE
customer1   3      84s

with -o yaml

$ kubectl get configmap customer1 -o yaml
apiVersion: v1
data:
  COMPANY: Customer1 Company Technology Pct. Ltd.
  TEXT1: Customer1_Company
  TEXT2: Welcomes You
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-01T02:06:55Z"
  name: customer1
  namespace: default
  resourceVersion: "126640"
  selfLink: /api/v1/namespaces/default/configmaps/customer1
  uid: f513b09f-fad4-41ec-a754-4cd55847c790

Create a ConfigMap from a File

First, create a file permission-reset.properties with the following data:

$ cat permission-reset.properties
permission=read-only
allowed="true"
resetCount=3

create from file

$ kubectl create configmap permission-config --from-file=permission-reset.properties
configmap/permission-config created

view config

$ kubectl get configmaps
NAME                DATA   AGE
customer1           3      87m
my-config           2      99m
permission-config   1      15m

$ kubectl get configmaps permission-config -o yaml
apiVersion: v1
data:
  permission-reset.properties: "permission=read-only\r\nallowed=\"true\"\r\nresetCount=3\r\n"
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-01T03:18:53Z"
  name: permission-config
  namespace: default
  resourceVersion: "136050"
  selfLink: /api/v1/namespaces/default/configmaps/permission-config
  uid: 7932c212-970c-41b0-95a3-f9481c289ba4

Use ConfigMaps Inside Pods (As Environment Varialbes)

Inside a Container, we can retrieve the key-value data of an entire ConfigMap or the values of specific ConfigMap keys as environment variables.
Exmaple : all the myapp-full-container Container's environment variables receive the values of the full-config-map ConfigMap keys:

...
  containers:
  - name: myapp-full-container
    image: myapp
    envFrom:
    - configMapRef:
      name: full-config-map
...

In the following example, the myapp-specific-container Container's environment variables receive their values from specific key-value pairs from separate ConfigMaps:

...
containers:
- name: myapp-specific-container
  image: myapp
  env:
  - name: SPECIFIC_ENV_VAR1
    valueFrom:
      configMapKeyRef:
        name: config-map-1
        key: SPECIFIC_DATA
  - name: SPECIFIC_ENV_VAR2
    valueFrom:
      configMapKeyRef:
        name: config-map-2
        key: SPECIFIC_INFO
...

from above, we will get the SPECIFIC_ENV_VAR1 environment variable set to the value of SPECIFIC_DATA key from config-map-1 ConfigMap, and SPECIFIC_ENV_VAR2 environment variable set to the value of SPECIFIC_INFO key from config-map-2 ConfigMap.

Use ConfigMaps Inside Pods (As Volumes)

We can mount a vol-config-map ConfigMap as a Volume inside a Pod.
For each key in the ConfigMap, a file gets created in the mount path(where the file is named with the key name) and the content of that file cecomes the respective key's value.
example:

...
containers:
- name: myapp-vol-container
  image: myapp
  volumeMounts:
  - name: config-volume
    mountPath: /etc/config
volumes:
- name: config-volume
  configMap:
    name: vol-config-map
...

more details on official document

Secrets

encode the sensitive information before sharing it.
share encode sensitive data in form of key-value pairs, similar to ConfigMaps.
the Secret object is referenced, without exposing its content.
Secret data is stored as plain text inside etcd.
Administrator must limit access to the API-server and etcd.
A newer feature allows for Secret data to be encrypted at rest while it is stored in etcd; a feature which needs to be enabled at the API server level.

Create a Secret from Literal and Display Its Details.

get help

$ kubectl create secret --help
Create a secret using specified subcommand.

Available Commands:
  docker-registry Create a secret for use with a Docker registry
  generic         Create a secret from a local file, directory or literal value
  tls             Create a TLS secret

Usage:
  kubectl create secret [flags] [options]

example

$ kubectl create secret generic my-password --from-literal=password=mysqlpassword
secret/my-password created

get it

$ kubectl get secret my-password
NAME          TYPE     DATA   AGE
my-password   Opaque   1      2m20s

describe it.

$ kubectl describe secret my-password
Name:         my-password
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:  13 bytes

they don't reveal the content of the Secret. The type is listed as Opaque.

Create a Secret Manually

create manually from a YAML configuration file.
two type of sensitive information inside a Secret: data and stringData.
with data maps, each value of a sensitive information field must be encoded using base64 (as always, encode != encrypt.)
example:

$ kubectl create secret generic my-password --type Opaque --from-literal=password=mysqlpassword --dry-run -o yaml
apiVersion: v1
data:
  password: bXlzcWxwYXNzd29yZA==
kind: Secret
metadata:
  creationTimestamp: null
  name: my-password
type: Opaque

save it to a file.

$ kubectl create secret generic my-password --type Opaque --from-literal=password=mysqlpassword --dry-run -o yaml > mypass.yaml

cat it.

$ cat mypass.yaml
apiVersion: v1
data:
  password: bXlzcWxwYXNzd29yZA==
kind: Secret
metadata:
  creationTimestamp: null
  name: my-password
type: Opaque

DO NOT commit a Secret's configuration file in the source code.
with stringData maps, there is no need to encode the value of each sensitive information field.
The value of the sensitive field will be encoded when the my-password Secret is created.
generate

$ kubectl create secret generic mypass-stringdata --type=Opaque --from-literal=password=mysqlpassword --dry-run -o yaml > mypass-stringdata.yaml

edit and cat it.

$ cat mypass-stringdata.yaml
apiVersion: v1
stringData:
  password: mysqlpassword
kind: Secret
metadata:
  creationTimestamp: null
  name: mypass-stringdata
type: Opaque

create it

$ kubectl delete secret my-password
secret "my-password" deleted

$ kubectl create -f mypass.yaml
secret/my-password created

$ kubectl create -f mypass-stringdata.yaml
secret/mypass-stringdata created

$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
default-token-7dldh   kubernetes.io/service-account-token   3      2d16h
my-password           Opaque                                1      76s
mypass-stringdata     Opaque                                1      36s

Create a Secret from a File and Display Its Details

$ echo mysqlpassword | base64
 bXlzcWxwYXNzd29yZAo=

$ cat password.txt
bXlzcWxwYXNzd29yZAo=

Now we ceate the Secret from the password.txt file:

$ kubectl create secret generic my-file-password --from-file=password.txt
secret/my-file-password created

we can analyze it with the get and describe command.

$ kubectl get secret my-file-password
NAME               TYPE     DATA   AGE
my-file-password   Opaque   1      45s

$ kubectl describe secret my-file-password
Name:         my-file-password
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password.txt:  22 bytes

User Secrets Inside Pods

Secrets are comsume by Containers in Pods as mounted data volumes, or as environment variables, and are referenced in their entirety or specific key-values

Using Secrets as Environment Variable

Example: the password key of the my-password Secret and assigned its value to the WORDPRESS_DB_PASSWORD environment.

...
spec:
  containers:
  - image: wordpress:4.7.3-apache
    name: wordpress
    env:
    - name: WORDPRESS_DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-password
          key: password
...

Using Secret as Files from a Pod

we can mount a Secret as a Volume insdie a Pod.
The following example create a file for each my-password Secret key(where the fiels are named after the names of the keys), the files containing the values of the Secret.

...
spec:
  containers:
  - image: wordpress:4.7.3-apache
    name: wordpress
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret-data"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-password
...

more details

Demo

$ kubectl create configmap web-config -n default --from-literal=STRING="Welcome to MY-NGINX!" --from-literal=PATH="/usr/share/nginx/html/index.html" --dry-run -o yaml

apiVersion: v1
data:
  PATH: /usr/share/nginx/html/index.html
  STRING: Welcome to MY-NGINX!
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: web-config
  namespace: default

create a file

$ kubectl create configmap web-config -n default --from-literal=STRING="Welcome to MY-NGINX!" --from-literal=PATH="/usr/share/nginx/html/index.html" --dry-run -o yaml > web-config.yaml

create it

$  kubectl create -f web-config.yaml
configmap/web-config created

describe it

$  kubectl describe cm web-config
Name:         web-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
PATH:
----
/usr/share/nginx/html/index.html
STRING:
----
Welcome to MY-NGINX!
Events:  <none>

create a pod configuration file.

$ kubectl run ap-config --image=nginx --restart=Never --env=DATA_STRING=xxx --env=DATA_PATH=xxx --dry-run -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: ap-config
  name: ap-config
spec:
  containers:
  - env:
    - name: DATA_STRING
      value: xxx
    - name: DATA_PATH
      value: xxx
    image: nginx
    name: ap-config
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

save to file.

$ kubectl run ap-config --image=nginx --restart=Never --env=DATA_STRING=xxx --env=DATA_PATH=xxx --dry-run -o yaml > app-config.yaml

vim it to the following.

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  name: ap-config
spec:
  containers:
  - env:
    - name: DATA_STRING
      valueFrom:
        configMapKeyRef:
          name: web-config
          key: STRING
          optional: true
    - name: DATA_PATH
      valueFrom:
        configMapKeyRef:
          name: web-config
          key: PATH
          optional: true
    image: nginx
    name: nginx
    command: [ "/bin/sh", "-c", "echo $(DATA_STRING) > $(DATA_PATH) ; sleep 3600" ]
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

create it

$ kubectl create -f app-config.yaml
pod/ap-config created

get pods

$ kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
ap-config   1/1     Running   0          2m10s
check-pod   1/1     Running   1          24h

exec command

$ kubectl exec --help
Execute a command in a container.

Examples:
  # Get output from running 'date' command from pod mypod, using the first container by default
  kubectl exec mypod date

  # Get output from running 'date' command in ruby-container from pod mypod
  kubectl exec mypod -c ruby-container date

  # Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod mypod
  # and sends stdout/stderr from 'bash' back to the client
  kubectl exec mypod -c ruby-container -i -t -- bash -il

  # List contents of /usr from the first container of pod mypod and sort by modification time.
  # If the command you want to execute in the pod has any flags in common (e.g. -i),
  # you must use two dashes (--) to separate your command's flags/arguments.
  # Also note, do not surround your command and its flags/arguments with quotes
  # unless that is how you would execute it normally (i.e., do ls -t /usr, not "ls -t /usr").
  kubectl exec mypod -i -t -- ls -t /usr

  # Get output from running 'date' command from the first pod of the deployment mydeployment, using the first container
by default
  kubectl exec deploy/mydeployment date

  # Get output from running 'date' command from the first pod of the service myservice, using the first container by
default
  kubectl exec svc/myservice date

Options:
  -c, --container='': Container name. If omitted, the first container in the pod will be chosen
      --pod-running-timeout=1m0s: The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one
pod is running
  -i, --stdin=false: Pass stdin to the container
  -t, --tty=false: Stdin is a TTY

Usage:
  kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

execute it.

$ kubectl create -f app-config.yaml
pod/ap-config created

verify it.

$ kubectl exec ap-config -- cat /usr/share/nginx/html/index.html
Welcome to MY-NGINX!

$ kubectl exec ap-config -- /bin/sh -c "cat /usr/share/nginx/html/index.html"
Welcome to MY-NGINX!