Secrets Should Be Encrypted At Rest

More Info:

Advisory: EncryptionConfiguration with a KMS provider should be enabled for Secret resources so etcd does not store secrets in plaintext.

Risk Level

High

Address

Security

Compliance Standards

• Cloudanix Best Practice

Triage and Remediation

Remediation

Remediation

Manual Steps

1. Identify the OKE cluster and its compartment

   • In the OCI Console, go to: Developer Services → Kubernetes Clusters (OKE).
   • Note the Compartment, Cluster name, and OCID of the cluster you are assessing.

2. Check if envelope encryption is enabled for the cluster (Console)

   • In the OKE cluster details page, open the Settings or Cluster tab.
   • Look for a field such as Encryption / Secrets encryption / KMS key.
   • Determine whether:
     • A KMS key is associated with the cluster for secrets encryption (envelope/KMS encryption enabled), or
     • No key is set (secrets stored in etcd are not KMS‑encrypted at rest).

3. Check cluster encryption via OCI CLI (any machine with OCI CLI configured)

   • Run:

     oci ce cluster get --cluster-id ocid1.cluster.oc1..exampleuniqueID --query 'data."options"."kubernetes-network-config".encryption' --raw-output

   • If the above key returns nothing or fails, retrieve all options and inspect for encryption/KMS fields:

     oci ce cluster get --cluster-id ocid1.cluster.oc1..exampleuniqueID --query 'data.options' 

   • Review the output for any field indicating a KMS key or secrets/envelope encryption configuration and note whether it is set.

4. Decide on the required KMS key and security posture (design decision)

   • With your security team, decide:
     • Which OCI Vault KMS key (OCID, key rotation policy, access policy) should be used for cluster secret encryption.
     • Which teams/principals may manage or rotate this key.
   • Confirm that the key’s IAM policy allows OKE to use it (Vault and Key policies granting the OKE service principal access).

5. Enable or update secrets encryption for the OKE cluster (Console/CLI/IaC)

   • If the cluster does not have KMS encryption enabled, or you need to change the key, update the cluster configuration:
     • Using the OCI Console: edit the cluster, set the KMS key for secrets/envelope encryption (exact UI labels may vary by OKE version), and save.
     • Using OCI CLI (if supported for your cluster version), for example:

       oci ce cluster update \
         --cluster-id ocid1.cluster.oc1..exampleuniqueID \
         --kubernetes-version <current-version> \
         --defined-tags file://defined-tags.json \
         --freeform-tags file://freeform-tags.json \
         --kms-key-id ocid1.key.oc1..examplekmsKeyID

       Adjust flags to match your existing cluster settings; the key part is setting --kms-key-id to the chosen KMS key OCID.
     • If managing via IaC (e.g., Terraform), add or update the OKE cluster’s KMS/encryption arguments to reference the chosen Vault key, then apply the change.

6. Verify that secrets encryption is now enabled (Console/CLI)

   • Re-open the OKE cluster in the OCI Console and confirm that the KMS key / Secrets encryption field now shows the expected key.
   • From the CLI, verify the encryption/KMS field is present and correctly set:

     oci ce cluster get --cluster-id ocid1.cluster.oc1..exampleuniqueID --query 'data.options' 

   • Confirm the options reflect an active association with your intended KMS key for secret/envelope encryption.

Using kubectl

kubectl cannot configure secret encryption at rest on Oracle OKE, because this setting is part of the managed control plane and must be enabled via OCI (console, CLI, or IaC such as Terraform). Refer to the Manual Steps section for how to review and configure KMS/envelope encryption for your OKE cluster.

Automation

#!/usr/bin/env bash
#
# Check Secret encryption-at-rest status on an OKE cluster (best-effort)
# Requirements:
#   - kubectl configured to talk to the target OKE cluster
#   - jq installed
#
# Run from: any machine with kubectl access

set -euo pipefail

echo "== OKE Secret Encryption-at-Rest Review =="

echo
echo "1) Describe all Kubernetes Secrets (redact data) to support manual review"
echo "   (This does NOT prove encryption at rest; it only helps identify"
echo "    unexpected or sensitive secrets that should be protected by envelope/KMS encryption.)"
echo

# List all namespaces
namespaces=$(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}')

for ns in $namespaces; do
  echo "Namespace: $ns"
  # Show metadata and type only (do not show secret data)
  kubectl get secrets -n "$ns" -o custom-columns=NAME:.metadata.name,TYPE:.type,AGE:.metadata.creationTimestamp --no-headers || true
  echo
done

echo "---------------------------------------------------------------"
echo "2) Detect Secrets that look like they might contain raw credentials"
echo "   (e.g., generic Opaque secrets with likely credential key names)"
echo

suspicious_keys='(?i)(password|passwd|token|secret|apikey|api_key|access_key|private_key|cert|certificate)'

kubectl get secrets --all-namespaces -o json \
  | jq -r --arg re "$suspicious_keys" '
    .items[]
    | . as $s
    | ($s.data // {}) as $d
    | [keys_unsorted[] | select(test($re))] as $sus
    | select($sus | length > 0)
    | "\($s.metadata.namespace) \($s.metadata.name) \($s.type) keys=" + ($sus | join(","))' \
  || true

echo
echo "If you see many sensitive Opaque secrets above, ensure OKE envelope/KMS"
echo "encryption is enabled at the cluster level via the OCI Console/CLI/IaC."
echo
echo "NOTE: On OKE, whether etcd uses KMS envelope encryption for Secrets is"
echo "configured on the control plane (Oracle-managed). It is NOT visible or"
echo "changeable via kubectl. This script only helps you identify secrets that"
echo "should be protected and to prioritize clusters for review in OCI."

How to interpret the output

• The script does not prove whether etcd is encrypting Secrets at rest; that setting is controlled in OKE at the cluster configuration level.
• It helps you:
  • List all Secrets by namespace and type so you can assess sensitivity and volume.
  • Highlight Secrets with likely credential fields (password, token, apikey, etc.) so you can:
    • Confirm the cluster’s OKE configuration uses envelope/KMS encryption for Secrets.
    • Prioritize enabling or tightening that setting on clusters with many sensitive secrets.

If you find clusters with many sensitive secrets and you are not certain OKE envelope/KMS encryption is enabled for them, treat that as a problem and review/enable the OKE KMS encryption option for those clusters in the Oracle Cloud Console or your OCI/IaC definitions.