Back to controls

Consider external secret storage

Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.

Category

Controls

Medium

Applies to

Kubernetes

Coverage

6 queries

Asset types

6 covered

Overview

Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.

Rationale

Kubernetes supports secrets as first-class objects, but care needs to be taken to ensure that access to secrets is carefully limited. Using an external secrets provider can ease the management of access to secrets, especially where secrets are used across both Kubernetes and non-Kubernetes environments.

Remediation guidance

Refer to the secrets management options offered by your cloud provider or a third-party secrets management solution.

Depending on the provider, check out the following resources:

AWS

Service-wide remediation

Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.

Kubernetes

Use admission policies, baseline cluster configuration, GitOps templates, and namespace or workload guardrails so new deployments follow the control by default.

Operational rollout

  1. Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
  2. Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
  3. Re-scan and track approved exceptions with an owner and expiry date.

Query logic

These are the stored checks tied to this control.

Kubernetes Deployments with templates that use Kubernetes Secrets

Connectors

Kubernetes

Covered asset types

Deployment

Expected check: eq []

{
  deployments(
    where: {
      podTemplate: {
        OR: [
          {
            containersTemplates_SOME: {
              env_SOME: { isValueFromSet: true, isSecretKeySelectorSet: true }
            }
          }
          { secretVolumes_NOT: [] }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}
Kubernetes Jobs with templates that use Kubernetes Secrets

Connectors

Kubernetes

Covered asset types

Job

Expected check: eq []

{
  jobs(
    where: {
      cronJobName: ""
      podTemplate: {
        OR: [
          {
            containersTemplates_SOME: {
              env_SOME: { isValueFromSet: true, isSecretKeySelectorSet: true }
            }
          }
          { secretVolumes_NOT: [] }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}
Kubernetes CronJobs with templates that use Kubernetes Secrets

Connectors

Kubernetes

Covered asset types

CronJob

Expected check: eq []

{
  cronJobs(
    where: {
      podTemplate: {
        OR: [
          {
            containersTemplates_SOME: {
              env_SOME: { isValueFromSet: true, isSecretKeySelectorSet: true }
            }
          }
          { secretVolumes_NOT: [] }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}
Kubernetes DaemonSets with templates that use Kubernetes Secrets

Connectors

Kubernetes

Covered asset types

DaemonSet

Expected check: eq []

{
  daemonSets(
    where: {      
      podTemplate: {
        OR: [
          {
            containersTemplates_SOME: {
              env_SOME: { isValueFromSet: true, isSecretKeySelectorSet: true }
            }
          }
          { secretVolumes_NOT: [] }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}
Kubernetes StatefulSets with templates that use Kubernetes Secrets

Connectors

Kubernetes

Covered asset types

StatefulSet

Expected check: eq []

{
  statefulSets(
    where: {      
      podTemplate: {
        OR: [
          {
            containersTemplates_SOME: {
              env_SOME: { isValueFromSet: true, isSecretKeySelectorSet: true }
            }
          }
          { secretVolumes_NOT: [] }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}
Kubernetes ReplicaSets with templates that use Kubernetes Secrets

Connectors

Kubernetes

Covered asset types

ReplicaSet

Expected check: eq []

{
  replicaSets(
    where: {     
      deploymentName: "" 
      podTemplate: {
        OR: [
          {
            containersTemplates_SOME: {
              env_SOME: { isValueFromSet: true, isSecretKeySelectorSet: true }
            }
          }
          { secretVolumes_NOT: [] }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon