ConfigMaps

Data in ConfigMaps in kubernetes is not encoded or encrypted and contains key-value pairs or plain configuration files in any format.

Here are a few uses of ConfigMaps:

• Pod env vars from single or multiple ConfigMaps
• Use ConfigMap values in Pod commands
• Populate Volume from ConfigMap
• Add ConfigMap data to specific path in Volume
• Set file names and access mode in Volume from ConfigMap data
• Can be used by system components and controllers.

Creating ConfigMaps

ConfigMaps can be created in one of the three following ways:

kubectl create configmap myconfigmap \ --from-literal=city=London \ --from-file=./myconfigmapfile.txt \ --from-file=./myconfigmapdirectory/ 

which results in the following ConfigMap:

k get configmap myconfigmap -o yaml apiVersion: v1 data: city: London kind: ConfigMap metadata: creationTimestamp: "2020-01-12T11:22:43Z" name: myconfigmap namespace: default ... 

Security Context

A security context defines privilege and access control settings for a Pod or Container so we can limit what processes running in containers can do. For example we can limit:

• the user ID of the process (UID)
• the Linux capabilities
• filesystem groups

If we want to enforce that containers cannot run their process as root user we can add runAsNonRoot: true to the pod spec. Or we can define a PodSecurityPolicy to that effect.

To automate the enforcement of security contexts, we can define PodSecurityPolicies (PSP)

Pod Security Policies are cluster-level rules that govern what a pod can do, what they can access, what user they run as...

For a PSP to be enabled we must first configure the admission controller of the controller-manager to contain PodSecurityPolicy.

Service Accounts

Service accounts are used by processes to access the API (a service account provides an identity for processes than run in a pod)