Lesson 08 — ConfigMaps & Secrets

Learning Objectives

By the end of this lesson, you will be able to:

Understand the purpose of ConfigMaps
Understand the purpose of Kubernetes Secrets
Differentiate between ConfigMaps and Secrets
Learn how applications consume configuration data
Identify common security risks involving Secrets
Understand enterprise secrets management
Apply security best practices for protecting sensitive information

Why This Matters

Every application requires configuration.

Examples include:

Database hostnames
API endpoints
Logging levels
Feature flags
Authentication tokens
Database passwords
API Keys
TLS Certificates
Cloud credentials

Hardcoding these values inside application code is a major security risk.

Instead, Kubernetes separates application configuration from application code using ConfigMaps and Secrets.

This approach improves:

Security
Flexibility
Portability
Configuration management
DevSecOps automation

Configuration vs Sensitive Data

Not all application data has the same sensitivity.

Example:

Configuration	Sensitive Data
Application Name	Database Password
Logging Level	API Key
Feature Flags	AWS Access Key
Environment Name	OAuth Token
Application Port	TLS Private Key

Configuration belongs in ConfigMaps.

Sensitive information belongs in Secrets.

What is a ConfigMap?

A ConfigMap stores non-sensitive application configuration.

Examples include:

Environment variables
Configuration files
Application settings
URLs
Feature toggles
Port numbers
Logging configuration

ConfigMaps allow applications to change behaviour without rebuilding container images.

ConfigMap Architecture

Application

↓

ConfigMap

↓

Configuration Values

• Environment
• URL
• Port
• Log Level

The application reads its configuration from the ConfigMap during startup.

Example ConfigMap

Application Name

GoHackersCloud Portal

Environment

Production

Log Level

INFO

Port

443

Notice that no sensitive information is stored.

Benefits of ConfigMaps

ConfigMaps provide:

Centralised configuration
Easier application updates
Environment-specific configuration
Separation of configuration from code
Simplified CI/CD deployments
Improved maintainability

What is a Kubernetes Secret?

A Secret stores sensitive information required by applications.

Examples include:

Database passwords
API tokens
AWS credentials
Azure credentials
GCP credentials
TLS certificates
SSH keys
OAuth tokens
Service Account tokens

Secrets should never be stored directly inside container images or application source code.

Secret Architecture

Application

↓

Kubernetes Secret

↓

Sensitive Data

• Password

• API Key

• Certificate

• Token

Applications retrieve Secrets securely at runtime.

Common Secret Types

Kubernetes supports several Secret types.

Secret Type	Purpose
Opaque	Generic secrets
kubernetes.io/tls	TLS certificates
kubernetes.io/dockerconfigjson	Container registry credentials
kubernetes.io/service-account-token	Service Account tokens
Basic Authentication	Username and password
SSH Authentication	SSH private keys

Each Secret type is designed for a specific use case.

How Applications Use Secrets

Applications can consume Secrets as:

Environment variables
Mounted files
Volume mounts
Configuration files

Example:

Application

↓

Reads Secret

↓

Database Password

↓

Connects Securely

This avoids embedding credentials directly in the application.

ConfigMaps vs Secrets

Feature	ConfigMap	Secret
Stores configuration	✅	❌
Stores passwords	❌	✅
Stores API Keys	❌	✅
Stores certificates	❌	✅
Stores feature flags	✅	❌
Stores application settings	✅	❌

Choosing the correct resource type is an important security practice.

Secret Storage

By default, Kubernetes stores Secrets in etcd.

Application

↓

API Server

↓

etcd

↓

Encrypted Secret

If etcd is compromised and Secrets are not encrypted, attackers may gain access to sensitive credentials.

Why Base64 is NOT Encryption

Many new Kubernetes users assume Secrets are encrypted because they appear unreadable.

In reality:

Password

↓

Base64 Encoding

↓

UGFzc3dvcmQxMjM=

Base64 is simply an encoding mechanism.

Anyone can decode it easily.

Real protection requires Encryption at Rest.

Encryption at Rest

Enterprise Kubernetes environments encrypt Secrets before storing them in etcd.

Example:

Secret

↓

Encryption Provider

↓

Encrypted Data

↓

etcd

Cloud providers such as Amazon EKS support encryption using AWS Key Management Service (AWS KMS).

Enterprise Secrets Management

Many organisations integrate Kubernetes with dedicated secrets management platforms.

Common solutions include:

AWS Secrets Manager
AWS Systems Manager Parameter Store
HashiCorp Vault
Azure Key Vault
Google Secret Manager

These platforms provide:

Secret rotation
Access auditing
Centralised management
Fine-grained permissions
Automatic key lifecycle management

Secret Rotation

Passwords and API keys should not remain unchanged indefinitely.

Example:

Old Password

↓

Rotate Secret

↓

Application Reloads

↓

New Password

Regular rotation reduces the impact of credential compromise.

Secret Access

Not every application should access every Secret.

Example:

Payment Service

↓

Payment Database Secret

✓ Allowed

------------------------

Monitoring Service

↓

Payment Database Secret

✗ Denied

Access should always follow the Principle of Least Privilege.

Enterprise Example

An online banking platform contains:

Authentication Service
Payment Service
Customer Portal

Each service uses:

ConfigMaps

API URLs
Logging configuration
Environment settings

Secrets

Database credentials
Payment gateway API keys
TLS certificates
OAuth client secrets

Each application only receives access to the Secrets it requires.

Common Security Risks

Security teams frequently discover:

Passwords stored inside ConfigMaps
Secrets committed to Git repositories
Plain-text credentials inside YAML files
Shared Secrets across applications
Excessive Secret permissions
Unencrypted etcd databases
Long-lived API keys
Hardcoded credentials inside container images
Missing Secret rotation
Public exposure of sensitive configuration

These mistakes can lead to credential theft and cluster compromise.

Best Practices

As a Kubernetes Security Engineer:

Store sensitive information only in Secrets.
Store non-sensitive configuration in ConfigMaps.
Enable Encryption at Rest.
Use AWS KMS or another key management solution.
Rotate Secrets regularly.
Apply RBAC to Secret access.
Avoid hardcoded credentials.
Use external secret management platforms for production.
Audit Secret access.
Remove unused Secrets promptly.

Configuration should be managed securely throughout the application lifecycle.

Enterprise Monitoring

Security teams should monitor:

Secret creation
Secret deletion
Secret modifications
Failed Secret access
RBAC changes
Secret rotation events
Unauthorised API requests
Unusual Secret usage
Configuration drift
Encryption failures

Monitoring helps detect misuse of sensitive information before it results in a security incident.

Real-World Scenario

A developer accidentally commits a Kubernetes Secret containing AWS access keys to a public Git repository.

An attacker discovers the repository within minutes and uses the exposed credentials to:

Launch EC2 instances for cryptocurrency mining.
Access sensitive Amazon S3 buckets.
Enumerate IAM roles.
Modify cloud resources.

If the organisation had:

Used AWS Secrets Manager
Rotated credentials regularly
Implemented Git secret scanning
Applied least privilege IAM permissions

the impact of the exposure would have been significantly reduced.

Best Practices Summary

Always remember:

ConfigMaps are for configuration.
Secrets are for sensitive information.
Base64 is not encryption.
Encrypt Secrets stored in etcd.
Limit Secret access using RBAC.
Rotate credentials regularly.
Integrate Kubernetes with enterprise secret management solutions.
Continuously monitor Secret usage.
Never expose credentials in source code or Git repositories.

Protecting Secrets is one of the most important responsibilities of a Kubernetes Security Engineer.

Key Takeaways

After completing this lesson, you should understand:

The purpose of ConfigMaps
The purpose of Kubernetes Secrets
The differences between ConfigMaps and Secrets
How applications consume configuration
Why Encryption at Rest is essential
Enterprise secrets management approaches
Security best practices for protecting credentials

These concepts prepare you for securing workloads that depend on sensitive configuration and lay the foundation for advanced identity and secrets management.

Knowledge Check

Question 1

Which Kubernetes resource is designed to store non-sensitive application configuration?

A. Secret
B. Deployment
C. ConfigMap
D. Service

Answer: C

Question 2

Which Kubernetes resource should store database passwords?

A. ConfigMap
B. Deployment
C. Secret
D. Namespace

Answer: C

Question 3

Why is Base64 encoding insufficient for protecting Kubernetes Secrets?

A. It increases file size.
B. It is an encoding method, not encryption.
C. It only works on Linux.
D. Kubernetes cannot decode Base64.

Answer: B

Question 4

Which AWS service is commonly used with Amazon EKS to encrypt Kubernetes Secrets?

A. Amazon CloudWatch
B. AWS KMS
C. Amazon Route 53
D. AWS Lambda

Answer: B

Question 5

Which of the following is considered an enterprise best practice?

A. Store passwords in ConfigMaps.
B. Commit Secrets to Git repositories.
C. Rotate Secrets regularly and restrict access using RBAC.
D. Share one Secret across all applications.

Answer: C

What’s Next?

In the next lesson, you will explore Persistent Storage, learning how Kubernetes manages persistent data using Volumes, Persistent Volumes (PVs), Persistent Volume Claims (PVCs), and Storage Classes, along with the security considerations for protecting enterprise data.

➡️ Next Lesson: Lesson 09 — Persistent Storage