Learning Hub
← DevOps & Infrastructure

Kubernetes configuration, secrets, ingress, and RBAC

6 min readΒ·Updated 2026-09-09

ConfigMaps hold non-secret configuration, Secrets carry sensitive values with careful handling, Ingress routes external HTTP traffic, and RBAC grants identities only the Kubernetes API actions they need.

ConfigMaps hold non-secret configuration, Secrets carry sensitive values with careful handling, Ingress routes external HTTP traffic, and RBAC grants identities only the Kubernetes API actions they need.

At a glance

Question Practical answer
When is it useful? A web workload reads a public feature flag from a ConfigMap, receives a credential through a Secret reference, is exposed through TLS Ingress, and runs under a restricted ServiceAccount.
What should you do? Deploy a sample namespace with least-privilege RBAC, reference configuration without baking it into the image, and test one allowed plus one denied action.
How do you know it worked? The app receives intended configuration, the credential is absent from source and image history, TLS works, and the denied API action returns forbidden.
Common failure Base64 encoding is not encryption; limit Secret access, use encryption at rest and an external secret manager when risk requires it.
flowchart LR
  A[Question] --> B[Kubernetes configuration, secrets, ingress]
  B --> C[Small example]
  C --> D[Evidence]

The important idea is not to stop at a definition: connect the concept to a small example and observable evidence.

Worked example

A web workload reads a public feature flag from a ConfigMap, receives a credential through a Secret reference, is exposed through TLS Ingress, and runs under a restricted ServiceAccount.

Before acting, write the success signal. Change one condition at a time, observe the result, and record assumptions. For Kubernetes configuration, secrets, ingress, and RBAC, this separates what you know from what you are merely guessing.

Practice in 20–30 minutes

Goal: Deploy a sample namespace with least-privilege RBAC, reference configuration without baking it into the image, and test one allowed plus one denied action.

  1. Record the starting state and your prediction.
  2. Implement the smallest version without adding unnecessary tools.
  3. Change exactly one input or constraint and repeat.
  4. Save a command, screenshot, output, or checklist as evidence.

Expected result: The app receives intended configuration, the credential is absent from source and image history, TLS works, and the denied API action returns forbidden.

What can go wrong

Base64 encoding is not encryption; limit Secret access, use encryption at rest and an external secret manager when risk requires it.

When the result differs from your prediction, do not change many things at once. Check inputs, versions, environment, permissions, and logs, then repeat from the smallest example.

Definition of done

  • I can explain the concept in my own words.
  • I completed the small example and kept evidence.
  • I know one failure mode and how to check it.
  • Someone else can repeat the work without guessing missing steps.

Go deeper

Use the linked resource or repository at the end of the page when you need a full implementation. Check current versions before applying commands to a real project.