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)