External secret management integration in Kubernetes - Step-by-Step Execution

Process Flow - External secret management integration

Define Secret in External Manager

↓

Configure Kubernetes External Secrets

↓

Kubernetes External Secrets Controller Fetches Secret

↓

Secret Created/Updated in Kubernetes

↓

Pod Uses Kubernetes Secret

↓

Application Accesses Secret

This flow shows how an external secret is defined outside Kubernetes, then fetched and synced into Kubernetes as a secret, which pods can then use.

Execution Sample

Kubernetes

apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
spec:
  backendType: secretsManager
  data:
  - key: prod/db-password
    name: password

This ExternalSecret resource tells Kubernetes to fetch the 'prod/db-password' from AWS Secrets Manager and create a Kubernetes secret with the key 'password'.

Process Table

Step	Action	Resource Involved	Result	Notes
1	Define secret in AWS Secrets Manager	AWS Secrets Manager	Secret 'prod/db-password' created	External secret stored securely outside Kubernetes
2	Create ExternalSecret resource in Kubernetes	Kubernetes ExternalSecret	ExternalSecret resource 'my-secret' created	Specifies which external secret to fetch
3	External Secrets Controller polls AWS	External Secrets Controller	Fetches 'prod/db-password' value	Controller runs inside Kubernetes cluster
4	Controller creates Kubernetes Secret	Kubernetes Secret	Secret 'my-secret' created with key 'password'	Secret synced from external manager
5	Pod references Kubernetes Secret	Pod spec	Pod mounts or env uses secret 'my-secret'	Application can access secret securely
6	Application reads secret	Application container	Secret value available at runtime	Used for DB connection or API keys
7	Secret updated externally	AWS Secrets Manager	Secret value changed	External secret updated
8	Controller detects change	External Secrets Controller	Updates Kubernetes Secret	Sync keeps secrets current
9	Pod uses updated secret	Pod	Application uses new secret value	No pod restart needed if mounted properly

💡 Secret synced and available in Kubernetes; application can securely use external secrets.

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 8	Final
External Secret Value	undefined	fetched 'prod/db-password' value	stored in Kubernetes Secret 'my-secret'	updated with new external value	current secret value in Kubernetes

Key Moments - 3 Insights

Why doesn't the application access the external secret directly?

The application accesses the Kubernetes Secret, not the external manager directly, because Kubernetes manages secrets securely inside the cluster and provides standard ways for pods to consume them. See execution_table steps 4 and 5.

How does the Kubernetes Secret stay updated when the external secret changes?

The External Secrets Controller continuously polls or watches the external secret and updates the Kubernetes Secret when changes occur, as shown in execution_table steps 7 and 8.

What happens if the External Secrets Controller is not running?

If the controller is not running, Kubernetes Secrets won't be created or updated from external sources, so pods may have stale or missing secrets. This is implied between steps 3 and 4.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Kubernetes create the secret from the external value?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Check the 'Result' column for when the Kubernetes Secret 'my-secret' is created.

According to the variable tracker, what is the state of the external secret value after step 8?

A Undefined

B Fetched but not stored

C Updated with new external value

D Deleted

💡 Hint

Look at the 'After Step 8' column for 'External Secret Value'.

If the External Secrets Controller stops running, what will happen to the Kubernetes Secret?

A It will stay but not update with external changes

B It will be deleted immediately

C It will update automatically

D Pods will crash

💡 Hint

Refer to key_moments about controller role and execution_table steps 3-4.

Concept Snapshot

External Secret Management Integration in Kubernetes:
- Define secrets in external manager (e.g., AWS Secrets Manager).
- Create ExternalSecret resource in Kubernetes specifying external keys.
- External Secrets Controller fetches and syncs secrets into Kubernetes Secrets.
- Pods consume Kubernetes Secrets as environment variables or volumes.
- Controller keeps secrets updated automatically without pod restarts.

Full Transcript

External secret management integration in Kubernetes involves storing secrets securely outside the cluster, such as in AWS Secrets Manager. You create an ExternalSecret resource in Kubernetes that tells the External Secrets Controller which external secrets to fetch. The controller runs inside the cluster, fetches the secret values, and creates or updates Kubernetes Secrets accordingly. Pods then use these Kubernetes Secrets to access sensitive data like passwords or API keys. When the external secret changes, the controller detects the update and syncs the new value into Kubernetes Secrets, keeping applications up to date without manual intervention. This process ensures secrets are managed securely and efficiently across systems.

Practice

1. What is the main purpose of using ExternalSecret in Kubernetes?

easy

A. To sync secrets from external secret stores into Kubernetes automatically

B. To create new Kubernetes namespaces

C. To monitor pod resource usage

D. To deploy applications without containers

Solution

1. Step 1: Understand ExternalSecret role

   ExternalSecret is designed to fetch and sync secrets from external secret management systems into Kubernetes.

2. Step 2: Compare options with purpose

   Only To sync secrets from external secret stores into Kubernetes automatically describes syncing secrets automatically, which matches ExternalSecret's main use.

3. Final Answer:

   To sync secrets from external secret stores into Kubernetes automatically -> Option A

4. Quick Check:

   ExternalSecret syncs external secrets = C [OK]

Hint: ExternalSecret = syncing external secrets into Kubernetes [OK]

Common Mistakes:

• Confusing ExternalSecret with namespace creation
• Thinking it manages pods or deployments
• Assuming it monitors resource usage

2. Which of the following is the correct syntax to define an ExternalSecret resource in Kubernetes?

easy

A. apiVersion: external-secrets.io/v1alpha1
kind: ExternalSecret
metadata:
name: my-secret
spec:
refreshInterval: 1h
secretStoreRef:
name: my-store
target:
name: synced-secret
data:
- secretKey: password
remoteRef:
key: prod/db-password

B. apiVersion: v1
kind: Secret
metadata:
name: my-secret
stringData:
password: prod/db-password

C. apiVersion: apps/v1
kind: Deployment
metadata:
name: secret-deployment
spec:
replicas: 1

D. apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
name: my-secret-store

Solution

1. Step 1: Identify ExternalSecret resource structure

   ExternalSecret uses apiVersion external-secrets.io/v1alpha1, kind ExternalSecret, and spec with secretStoreRef and data fields.

2. Step 2: Match syntax with options

   apiVersion: external-secrets.io/v1alpha1 kind: ExternalSecret metadata: name: my-secret spec: refreshInterval: 1h secretStoreRef: name: my-store target: name: synced-secret data: - secretKey: password remoteRef: key: prod/db-password matches the correct syntax for ExternalSecret resource definition including refreshInterval, secretStoreRef, and data mapping.

3. Final Answer:

   Correct ExternalSecret resource syntax -> Option A

4. Quick Check:

   ExternalSecret syntax = apiVersion: external-secrets.io/v1alpha1 kind: ExternalSecret metadata: name: my-secret spec: refreshInterval: 1h secretStoreRef: name: my-store target: name: synced-secret data: - secretKey: password remoteRef: key: prod/db-password [OK]

Hint: Look for apiVersion external-secrets.io and kind ExternalSecret [OK]

Common Mistakes:

• Using Secret kind instead of ExternalSecret
• Confusing SecretStore with ExternalSecret
• Wrong apiVersion or missing spec fields

3. Given this ExternalSecret YAML snippet, what will be the name of the Kubernetes Secret created?

spec:
  target:
    name: app-secret
  data:
  - secretKey: api-key
    remoteRef:
      key: prod/api-key

medium

A. prod/api-key

B. external-secret

C. api-key

D. app-secret

Solution

1. Step 1: Understand target.name in ExternalSecret

   The target.name field specifies the name of the Kubernetes Secret that will be created or updated.

2. Step 2: Identify the value in target.name

   Here, target.name is set to "app-secret", so the Kubernetes Secret will be named "app-secret".

3. Final Answer:

   app-secret -> Option D

4. Quick Check:

   target.name sets Secret name = app-secret [OK]

Hint: target.name is the Kubernetes Secret name [OK]

Common Mistakes:

• Confusing remoteRef.key with Secret name
• Using secretKey as Secret name
• Assuming default name external-secret

4. You applied an ExternalSecret manifest but the Kubernetes Secret is not created. Which is the most likely cause?

medium

A. The pod does not have enough CPU resources

B. The Kubernetes API server is down

C. The ExternalSecret controller is not installed or running in the cluster

D. The Deployment spec is missing replicas

Solution

1. Step 1: Identify role of ExternalSecret controller

   The ExternalSecret controller watches ExternalSecret resources and creates Kubernetes Secrets accordingly.

2. Step 2: Analyze why Secret is not created

   If the controller is missing or not running, ExternalSecret resources won't be processed, so no Secrets are created.

3. Final Answer:

   The ExternalSecret controller is not installed or running in the cluster -> Option C

4. Quick Check:

   Missing controller = no Secret creation [OK]

Hint: Check if ExternalSecret controller pod is running [OK]

Common Mistakes:

• Blaming pod CPU resources for Secret creation
• Assuming API server downtime without checking
• Confusing Deployment replicas with secret syncing

5. You want to sync a secret from AWS Secrets Manager into Kubernetes using ExternalSecret. Which two key configurations must you include in your ExternalSecret manifest?

hard

A. podSelector to select pods and replicas for scaling

B. secretStoreRef to specify AWS Secrets Manager and data with remoteRef key

C. container image and command to run the sync

D. nodeSelector to assign nodes and tolerations for scheduling

Solution

1. Step 1: Identify required ExternalSecret fields for AWS integration

   You must specify secretStoreRef to point to the AWS Secrets Manager store and data with remoteRef key to map the secret key.

2. Step 2: Exclude unrelated fields

   podSelector, replicas, container image, nodeSelector, and tolerations are unrelated to ExternalSecret syncing secrets.

3. Final Answer:

   secretStoreRef to specify AWS Secrets Manager and data with remoteRef key -> Option B

4. Quick Check:

   secretStoreRef + data.remoteRef = AWS secret sync [OK]

Hint: Use secretStoreRef and data.remoteRef for external secrets [OK]

Common Mistakes:

• Confusing pod or node selectors with secret syncing
• Trying to specify container image in ExternalSecret
• Missing secretStoreRef or data fields