Lesson 05 — Kubernetes Secrets

Welcome

Secrets are one of the most valuable assets inside a Kubernetes cluster.

Applications require credentials to communicate with databases, cloud services, APIs, message queues, and third-party platforms. Kubernetes provides the Secrets resource to securely store and distribute this sensitive information to workloads.

Unfortunately, Kubernetes Secrets are frequently misconfigured. Weak access controls, excessive RBAC permissions, exposed Service Account tokens, and poor secrets management practices can allow attackers to obtain credentials that lead to complete cluster or cloud compromise.

As a Cloud Penetration Tester, your objective is not simply to locate secrets—it is to evaluate whether secrets are securely managed throughout their lifecycle.

In this lesson, you will learn how Kubernetes Secrets work, common attack paths, enterprise security best practices, and how security consultants assess secrets management during real-world Kubernetes engagements.

Learning Objectives

After completing this lesson, you will be able to:

Understand Kubernetes Secrets.
Identify different Secret types.
Understand how applications consume secrets.
Identify common secrets management risks.
Understand Service Account tokens.
Assess secrets security.
Review enterprise secrets governance.
Recommend secure secrets management practices.

Business Scenario

CloudNova Technologies has been contracted to perform a Kubernetes security assessment for an enterprise organization.

The customer hosts multiple production applications that rely on Kubernetes Secrets for database credentials, API keys, TLS certificates, and cloud authentication.

Management wants assurance that sensitive information is protected against unauthorized access and that secrets management follows industry best practices.

Your responsibility is to review the organization’s secrets management implementation and identify security risks.

What are Kubernetes Secrets?

A Kubernetes Secret is an object used to store sensitive information required by applications.

Examples include:

Database passwords
API Keys
OAuth Tokens
TLS Certificates
SSH Keys
Cloud Credentials
Service Account Tokens
Application Secrets

Secrets allow applications to access sensitive information without embedding credentials directly into container images or application code.

Common Secret Types

Kubernetes supports several Secret types.

Opaque

General-purpose key-value secrets.

Examples:

Passwords
API Keys
Tokens

TLS

Stores TLS certificates.

Typically contains:

Certificate
Private Key

Docker Registry

Stores credentials used to authenticate with container registries.

Examples:

Artifact Registry
Docker Hub
Amazon ECR
Azure Container Registry

Service Account Token

Automatically generated credentials used by workloads to authenticate with the Kubernetes API Server.

These tokens often become high-value targets during penetration tests.

How Applications Use Secrets

Applications commonly consume Secrets through:

Environment Variables
Mounted Volumes
CSI Secret Store
External Secrets Operators
Cloud Secret Management Services

Understanding how secrets are consumed helps identify potential exposure points.

Kubernetes Secrets Architecture

Application

↓

Pod

↓

Secret

↓

Kubernetes API Server

↓

etcd

Secrets are stored within etcd, making protection of both etcd and API access critical to cluster security.

Why Attackers Target Secrets

Secrets often provide access to systems beyond Kubernetes.

Compromised secrets may expose:

Cloud Accounts
Databases
Internal APIs
Kubernetes API
CI/CD Platforms
Source Code Repositories
Monitoring Systems
External SaaS Platforms

Because of this, secrets are frequently one of the first targets during a Kubernetes security assessment.

Common Secrets Security Risks

Consultants commonly identify:

Secrets stored in plain text
Excessive RBAC access
Secrets exposed as environment variables
Shared credentials
Unused secrets
Long-lived Service Account tokens
Hardcoded application credentials
Missing secret rotation
Weak encryption practices

Service Account Tokens

Every Kubernetes Service Account may receive an authentication token.

These tokens allow workloads to communicate with the Kubernetes API.

Assess:

Token permissions
Token lifetime
Mounted tokens
RBAC permissions
Namespace scope

Compromised Service Account tokens may enable privilege escalation if overly permissive.

Enterprise Secrets Assessment

During an enterprise engagement, review:

Secret Inventory

Document:

Secret Name
Namespace
Owner
Purpose
Application
Last Updated

Access Control

Review:

RBAC permissions
Namespace isolation
Service Account access
Administrative access

Validate that only authorized identities can access sensitive information.

Secret Lifecycle

Review:

Creation
Rotation
Expiration
Revocation
Deletion

Determine whether the organization follows a defined lifecycle for managing secrets.

Encryption

Verify:

Encryption at Rest
Encryption in Transit
etcd Encryption
Key Management

Encryption should protect sensitive information throughout its lifecycle.

Secret Rotation

Review:

Rotation frequency
Automation
Expired credentials
Emergency rotation procedures

Regular rotation reduces the impact of compromised credentials.

Enterprise Best Practices

Organizations should:

Apply the Principle of Least Privilege.
Avoid hardcoding credentials.
Rotate secrets regularly.
Encrypt secrets at rest.
Limit Service Account permissions.
Use namespace isolation.
Audit secret access.
Monitor for unauthorized access.
Integrate external secret management platforms where appropriate.

Common Security Findings

Enterprise Kubernetes assessments frequently identify:

Secrets accessible by unnecessary users.
Over-privileged Service Accounts.
Credentials embedded in container images.
Credentials committed to source code.
Missing encryption configuration.
No secret rotation process.
Shared application credentials.
Long-lived API tokens.
Weak audit logging.
Missing ownership documentation.

Consultant Best Practices

Professional consultants should:

Review every Secret within scope.
Validate business ownership.
Assess RBAC before reviewing secret contents.
Avoid exposing sensitive values during assessments.
Confirm encryption settings.
Review Service Account permissions separately.
Document findings with supporting evidence.
Prioritize remediation based on business impact.

Key Takeaways

Kubernetes Secrets protect sensitive application data.
Service Account tokens require the same level of protection as user credentials.
RBAC is the primary control governing access to Secrets.
Encryption, rotation, and auditing are essential components of secure secrets management.
Poor secrets management can lead to cluster compromise and cloud account exposure.
Enterprise security assessments should evaluate the complete secrets lifecycle, not just secret storage.

Lesson Summary

In this lesson, you learned how Kubernetes stores and manages sensitive information, the different Secret types, common attack techniques, and how consultants assess secrets management during enterprise Kubernetes security engagements.

Understanding Secrets is fundamental to securing Kubernetes environments because compromised credentials often provide attackers with access to critical applications, cloud services, and administrative resources.

What’s Next?

➡️ Lesson 06 — Pod Security

In the next lesson, you will learn how attackers target Kubernetes Pods, identify insecure workload configurations, abuse privileged containers, and how security consultants assess Pod Security during enterprise Kubernetes penetration testing engagements.