External secret management integration in Kubernetes - Commands & Configuration

Introduction

Managing sensitive data like passwords or API keys directly in Kubernetes can be risky. External secret management integration helps keep these secrets safe by storing them outside Kubernetes and injecting them securely when needed.

When you want to keep database passwords out of Kubernetes configuration files to reduce risk of leaks.

When multiple applications need access to the same secret stored centrally and updated automatically.

When you want to rotate secrets regularly without redeploying your Kubernetes workloads.

When compliance rules require secrets to be stored in a dedicated secure vault.

When you want to audit who accessed or changed secrets outside Kubernetes.

Config File - externalsecret.yaml

externalsecret.yaml

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-database-secret
  namespace: default
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: my-vault
    kind: ClusterSecretStore
  target:
    name: database-credentials
    creationPolicy: Owner
  data:
  - secretKey: username
    remoteRef:
      key: database/creds
      property: username
  - secretKey: password
    remoteRef:
      key: database/creds
      property: password

This file defines an ExternalSecret resource that tells Kubernetes to fetch secrets from an external vault.

apiVersion and kind specify the resource type.

metadata names the secret and sets the namespace.

spec contains the details: how often to refresh, which external secret store to use, and what keys to fetch.

target defines the Kubernetes Secret name to create with the fetched data.

data maps keys from the external vault to keys in the Kubernetes Secret.

Commands

This command creates the ExternalSecret resource in Kubernetes, which starts the process of fetching secrets from the external vault and creating a Kubernetes Secret.

Terminal

kubectl apply -f externalsecret.yaml

Expected Output

externalsecret.external-secrets.io/my-database-secret created

This command checks that the Kubernetes Secret named 'database-credentials' was created and contains the data fetched from the external secret store.

Terminal

kubectl get secret database-credentials -o yaml

Expected Output

apiVersion: v1

data:

  password: cGFzc3dvcmQ=

  username: dXNlcg==

kind: Secret

metadata:

  name: database-credentials

  namespace: default

type: Opaque

→

-o yaml - Outputs the secret in YAML format to see its contents (base64 encoded)

This command shows details about the ExternalSecret resource, including status and any errors fetching secrets.

Terminal

kubectl describe externalsecret my-database-secret

Expected Output

Name:         my-database-secret

Namespace:    default

Labels:       <none>

Annotations:  <none>

API Version:  external-secrets.io/v1beta1

Kind:         ExternalSecret

Metadata:

  Creation Timestamp:  2024-06-01T12:00:00Z

Spec:

  Refresh Interval:  1h

  Secret Store Ref:

    Kind:  ClusterSecretStore

    Name:  my-vault

  Target:

    Creation Policy:  Owner

    Name:             database-credentials

  Data:

    Secret Key:  username

    Remote Ref:

      Key:       database/creds

      Property:  username

    Secret Key:  password

    Remote Ref:

      Key:       database/creds

      Property:  password

Status:

  Conditions:

    Type:    Ready

    Status:  True

Key Concept

If you remember nothing else from this pattern, remember: External secrets keep sensitive data safe by fetching it securely from outside Kubernetes and injecting it only when needed.

Common Mistakes

Not creating or configuring the external secret store (like Vault) before applying the ExternalSecret resource.

Kubernetes cannot fetch secrets without a properly configured external secret store, so the ExternalSecret will fail.

Set up and configure the external secret store and the ClusterSecretStore resource in Kubernetes before creating ExternalSecret resources.

Using incorrect keys or property names in the ExternalSecret data mapping.

If the keys do not match those in the external vault, the secret data will not be fetched correctly.

Verify the exact keys and properties in the external vault and use those names in the ExternalSecret spec.

Trying to access the Kubernetes Secret before the ExternalSecret controller has fetched and created it.

The Secret will not exist yet, causing errors in applications that depend on it.

Wait a few moments after applying the ExternalSecret and check its status before using the Kubernetes Secret.

Summary

Create an ExternalSecret resource to define which secrets to fetch from an external vault.

Apply the ExternalSecret with kubectl to start syncing secrets into Kubernetes.

Verify the Kubernetes Secret is created with the fetched data using kubectl get secret.

Use kubectl describe to check the ExternalSecret status and troubleshoot if needed.

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