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.
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 ...
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 are used by processes to access the API (a service account provides an identity for processes than run in a pod)