Configuration, secrets and traffic from outside
🎯You'll be able to
Pass settings and secrets to pods, understand how Kubernetes Secrets are stored, and route outside traffic to a Service.
🏠The everyday picture
A hotel's front desk hands each guest a printed welcome card (the Wi-Fi name, breakfast times) and, separately, a sealed envelope with the room safe's code. One gate at the front leads guests to the right building.
📘What it really is
- A ConfigMap holds ordinary settings (
LOG_LEVEL=info), passed to pods as environment variables or files. -
A Secret holds private values (
DATABASE_URLwith its password):yaml apiVersion: v1 kind: Secret metadata: { name: routerani-db } type: Opaque stringData: DATABASE_URL: postgres://routerani:CHANGE_ME@db:5432/routeraniand in the container:envFrom: [{ secretRef: { name: routerani-db } }]. -
How Secrets are protected:
- Secret values are stored base64-encoded, which is a format, not encryption. Anyone who can read the Secret can decode it;
- encryption at rest depends on how the cluster is set up; managed services offer encryption with a cloud key service;
- control who can read Secrets with RBAC (roles and role bindings), per namespace;
- many teams keep the real secret in a cloud secrets manager and sync it into the cluster (for example with the External Secrets Operator), so it isn't written in YAML files in Git.
- Traffic from outside:
- a Service of type
LoadBalancergets a cloud load balancer per Service, which is simple but can be costly with many services; - an Ingress (or the newer Gateway API) routes many hostnames and paths through one entry point, handled by a controller such as a cloud's own, Traefik or Envoy Gateway. The once-popular ingress-nginx project was retired in 2026, and new setups are encouraged to use the Gateway API. TLS certificates are often issued automatically by cert-manager.
📝A worked example
Input (not verified): kubectl create secret generic routerani-db --from-literal=DATABASE_URL='postgres://routerani:<generated>@db:5432/routerani',
then kubectl get secret routerani-db -o yaml.
Expected output: the YAML shows DATABASE_URL: followed by a long base64 string. kubectl get secret routerani-db -o jsonpath='{.data.DATABASE_URL}' | base64 -d
prints the original value, which shows why access to Secrets must be limited.
🌍Where it's used
- Every app on Kubernetes gets settings from ConfigMaps and Secrets.
- Banks and health platforms sync secrets from a central vault and audit who read them.
- Ingress controllers front most web apps on Kubernetes.
📝Case scenario
An edtech company committed Kubernetes Secret YAML files to Git, believing the base64 values were encrypted. A student intern decoded one in seconds during a hackathon and reported it. The team rotated the passwords, removed the files from Git, and moved to a secrets manager with a sync operator, so the repository held only the secret names.
🖱️Try it
Run echo -n 'postgres://routerani:Example123@db:5432/routerani' | base64 and then decode the result with base64 -d (on Windows PowerShell,
use [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('<the string>'))). Success: you've seen that base64 hides nothing.
⚠️Common mistakes
- Secret YAML in Git. Sign: base64 strings in the repository. Fix: create secrets from a secrets manager or the pipeline, never from committed files.
- Everyone can read Secrets. Sign: broad roles such as cluster-admin for developers. Fix: RBAC per namespace with least privilege.
- A cloud load balancer per service. Sign: a surprising bill with 30 services. Fix: one Ingress or Gateway for many services.
🛠️For your project
RouteRani's Project 1 keeps the password out of Git with random_password; on Kubernetes the same goal is met with a secrets manager and RBAC.
✅Quick check
Is base64 encryption?
Show the answer
No, it's an encoding that anyone can reverse.
What does an Ingress add over a LoadBalancer Service?
Show the answer
One entry point that routes many hostnames and paths to different Services.