← Back to Recording

Summary

Overview

This course session provides a hands-on introduction to Kubernetes ConfigMaps and Secrets, focusing on their creation, usage, and differences in handling configuration data—particularly the distinction between non-sensitive (ConfigMap) and sensitive (Secret) data. The session includes practical labs demonstrating how to mount ConfigMaps via environment variables and volumes, observe update behaviors, and securely store and use TLS certificates as Secrets. Emphasis is placed on secure practices, including the use of base64 encoding (with caveats about its non-encryption nature), secret type classification, and volume-based mounting for dynamic updates.

Topic (Timeline)

1. ConfigMap Management and Update Behavior [00:00:00 - 00:04:41]

  • Instructor guides learners through creating a Pod and applying a ConfigMap.
  • Demonstrates two methods of consuming ConfigMap data: via environment variables (ENV) and via volume mounting.
  • Shows that changes to a ConfigMap are not reflected in environment variables after Pod creation—values are static at Pod startup.
  • Confirms that changes to a ConfigMap are reflected in real-time when mounted as a volume: learners are instructed to modify a ConfigMap (e.g., change database name from “mysql” to “mongodb”), reapply it, and verify updates by running cat on the mounted file under /etc/config.
  • Learners are directed to exec into Pods using both methods to observe the difference: volume-mounted data updates; ENV data remains unchanged.

2. Introduction to Kubernetes Secrets [00:04:44 - 00:08:58]

  • Defines Secrets as containers for sensitive data (passwords, tokens, private keys) that should not be exposed in plain text in YAML files.
  • Clarifies that Kubernetes does not encrypt Secrets by default—base64 encoding is merely obfuscation; learners must implement external encryption and access controls.
  • Introduces Secret types: opaque (generic), kubernetes.io/service-account-token, kubernetes.io/dockerconfigjson, kubernetes.io/basic-auth, and kubernetes.io/ssh-auth.
  • Explains how annotations can be used to classify Secret types for easier management and filtering.
  • Demonstrates base64 encoding of values (e.g., username/password) for inclusion in Secret YAML, and shows how to create a Secret using kubectl create secret generic.

3. Retrieving and Mounting Secrets [00:08:59 - 00:13:59]

  • Shows how to reference Secret data in a Pod spec: mapping Secret keys to environment variables (e.g., secret_username) or mounting as files in a volume.
  • Guides learners to exec into a Pod and use env to view environment variables populated from Secrets.
  • Demonstrates volume mounting: Secret data appears as files under the specified mount path (e.g., /data/db/username, /data/db/password).
  • Learners are instructed to verify content by running cat on mounted files within the Pod.
  • Emphasizes that Secret data, like ConfigMap, is static in ENVs and dynamic in volumes.

4. TLS Certificates as Secrets – Lab Implementation [00:14:02 - 00:22:32]

  • Introduces TLS certificates (public cert and private key) as a use case for Secrets, explaining their role in encrypting traffic between clients and services (e.g., bank websites, Pod-to-API communication).
  • Instructs learners to:
    • Locate and inspect certificate (*.crt) and private key (*.key) files on the host.
    • Create a generic Secret using kubectl create secret generic with the certificate and key as files.
    • Verify the Secret with kubectl describe secret.
  • Guides creation of a Pod YAML that mounts the TLS Secret as a volume at a specified path (e.g., /etc/tls).
  • Demonstrates port-forwarding to the Pod and observing logs to confirm TLS certificate usage during outbound communication.
  • Confirms successful integration by checking Pod logs for TLS handshake or connection activity.

5. Summary and Break [00:22:38 - 00:23:20]

  • Recap: ConfigMaps for non-sensitive configuration; Secrets for sensitive data; both can be mounted via ENV (static) or volume (dynamic).
  • Reinforces that Secrets require additional security measures beyond base64 encoding.
  • Announces break, concluding the session.

Appendix

Key Principles

  • ConfigMaps: Store non-sensitive configuration. Updates via volume are live; updates via ENV require Pod restart.
  • Secrets: Store sensitive data (passwords, keys, tokens). Base64 is not encryption—assume data is readable by anyone with cluster access.
  • Secret Types: Use specific types (kubernetes.io/basic-auth, kubernetes.io/tls, etc.) for clarity and tooling support; default to opaque only when no specific type applies.
  • Mounting: Volume mounting enables dynamic updates; ENV mounting is static and suitable for immutable values.

Tools Used

  • kubectl create configmap
  • kubectl create secret generic
  • kubectl describe secret
  • kubectl exec -it <pod> -- bash
  • cat to inspect mounted files
  • env to list environment variables
  • base64 for encoding values (for demonstration only)
  • curl and port-forwarding to test TLS connectivity

Common Pitfalls

  • Assuming base64-encoded Secrets are secure (they are not—anyone with kubectl get secret -o yaml can decode them).
  • Expecting ENV variables to update when ConfigMap/Secret changes (they do not—Pod must be restarted).
  • Using opaque without annotations, making Secret purpose unclear in large environments.

Practice Suggestions

  • Re-create the labs with different Secret types (e.g., dockerconfigjson for registry auth).
  • Test ConfigMap updates with a real application (e.g., Nginx config) and observe reload behavior.
  • Use kubectl get secret <name> -o jsonpath='{.data.<key>}' | base64 --decode to decode and verify Secret contents.
  • Experiment with kubectl create secret tls for TLS certificate creation (alternative to generic).