> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # 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 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: ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} oci ce cluster update \ --cluster-id ocid1.cluster.oc1..exampleuniqueID \ --kubernetes-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: ```bash theme={null} 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. 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. ```bash theme={null} #!/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.