89% of Kubernetes Deployments Not Using Secrets Resources: Key Findings from Alcide’s 2019 Analysis

Originally reported via GlobeNewswire on July 15, 2019. Source: Alcide press release.

Overview

In mid-2019, Kubernetes security company Alcide published findings from a cross-environment analysis conducted using its Alcide Advisor tool — a multi-cluster vulnerability scanner designed to audit Kubernetes and Istio environments against security best practices and compliance benchmarks. The results painted a concerning picture of how organizations were (or weren’t) handling sensitive configuration data and network segmentation in their Kubernetes workloads.

Key Findings

The analysis surfaced three significant gaps in Kubernetes security hygiene across the scanned environments:

• 89% of deployment scans showed that organizations were not using Kubernetes’ native Secrets resources. Instead, sensitive values such as credentials, tokens, and API keys were being wired into workloads in plain text — whether via environment variables, ConfigMaps, or container image layers.
• Over 75% of scanned deployments used workloads that mounted high-risk host file systems, including /proc, which can expose sensitive kernel and process information and widen the attack surface significantly.
• None of the surveyed environments had implemented network segmentation using Kubernetes’ native NetworkPolicy resources, meaning workloads could communicate freely within the cluster with no enforced isolation boundaries.

Why Kubernetes Secrets Matter

Kubernetes Secrets are objects designed to store and manage sensitive information — such as passwords, OAuth tokens, and SSH keys — separately from application code and pod specifications. When used correctly, Secrets reduce the risk of sensitive data being accidentally committed to version control, baked into container images, or exposed through environment variable inspection.

However, Secrets are not encrypted at rest by default in older Kubernetes versions, and they are base64-encoded (not encrypted) within etcd unless cluster operators explicitly configure encryption at rest. Simply adopting Secrets is a meaningful step forward compared to plaintext embedding, but it is not sufficient on its own. Teams should also:

• Enable etcd encryption at rest for Secret objects.
• Use RBAC to restrict which service accounts and users can read Secrets.
• Consider integrating with an external secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for stronger lifecycle management.
• Avoid passing Secrets as environment variables where possible; mounting them as files reduces certain exposure vectors.

The Risk of Mounting Sensitive Host Paths

Mounting host file system paths such as /proc into a container gives that container visibility into — and in some cases the ability to interact with — low-level kernel and process data. This is occasionally necessary for observability or system-level tooling, but should be treated as an exception rather than a default. When misused or misconfigured, these mounts can enable container escape or privilege escalation attacks. Security-conscious teams should:

• Audit all hostPath volume mounts in pod specifications.
• Apply PodSecurityPolicy (deprecated in Kubernetes 1.21+) or its successor, Pod Security Admission, to restrict which host paths workloads may mount.
• Avoid mounting /proc, /sys, or / unless there is a documented, reviewed operational need.

The Absence of Network Policies

Kubernetes NetworkPolicy resources allow teams to define rules that govern how pods communicate with each other and with external endpoints. Without any NetworkPolicy applied, all pods in a cluster can, by default, communicate freely — a flat network topology that violates the principle of least privilege and makes lateral movement trivially easy for an attacker who compromises any single workload.

That none of the environments surveyed by Alcide had implemented any NetworkPolicy was one of the starkest findings in the report. Implementing even basic default-deny ingress and egress policies, then selectively allowing required traffic, dramatically reduces the blast radius of a compromised pod.

Alcide Advisor and Azure DevOps Integration

Alongside the findings, Alcide announced that Alcide Advisor had been integrated with Azure DevOps, making it available in the Microsoft Visual Studio Marketplace at the time of the announcement. The integration was designed to embed continuous Kubernetes security scanning directly into CI/CD pipelines, covering:

• Vulnerability scanning of master API server and worker node components, including container runtimes.
• Support for multiple cluster types, including AKS, Kops, and AKS Engine.
• Continuous configuration drift detection across multi-team, multi-cluster environments.

The goal was to shift security checks left — catching misconfigurations and policy violations during development and staging rather than after production deployment.

Practitioner Perspective

David J. Brewer, founder of Eupraxia Labs — a software vendor running workloads on Azure AKS — was quoted in the announcement:

“With Alcide Kubernetes Advisor, Eupraxia Labs has been able to significantly reduce security drifts in our entire CI/CD pipeline — from development and staging, all the way to production.”

David J. Brewer, Founder, Eupraxia Labs

Gadi Naor, CTO and co-founder of Alcide, noted the broader challenge:

“The increasing complexity of multi-cluster Kubernetes environments and the persistent lack of connectivity with DevOps workflows is complicating efforts by DevOps teams to keep pace with vulnerabilities and best practices. Alcide Advisor automates and integrates cluster hygiene into the CD process natively, to arm DevOps teams to immediately identify potential vulnerabilities, configuration drifts and threats, without sacrificing agility.”

Gadi Naor, CTO and Co-founder, Alcide

Practical Takeaways for DevOps Teams

Whether or not you use a dedicated scanning tool, the gaps identified in this analysis point to a concrete checklist for improving Kubernetes security hygiene:

1. Audit for plaintext secrets. Scan your pod specs, ConfigMaps, and Helm values files for hardcoded credentials. Migrate to Kubernetes Secrets objects, then consider an external secrets management solution.
2. Enable etcd encryption at rest to protect Secret data stored in the cluster datastore.
3. Review and restrict hostPath mounts. Any mount of sensitive host paths should have a documented justification and be gated by Pod Security Admission or an equivalent admission controller.
4. Define NetworkPolicies. Start with a default-deny baseline policy and explicitly allow only the traffic your application requires. Use a CNI plugin that enforces NetworkPolicy (e.g., Calico, Cilium, Weave Net).
5. Integrate security scanning into your CI/CD pipeline. Static analysis of Kubernetes manifests can catch many of these issues before deployment. Tools in this space include open-source options such as Trivy, kube-bench, kube-score, and Checkov, as well as commercial products.
6. Apply RBAC rigorously. Limit which identities can read Secrets, access the API server, or modify workload specs.

Context and Caveats

This analysis dates from mid-2019 — an early period in the mainstream adoption of Kubernetes in enterprise environments. The Kubernetes ecosystem and the security tooling around it have matured considerably since then. However, the underlying security hygiene gaps identified — plaintext secrets, over-permissive host mounts, and absent network policies — remain common findings in Kubernetes audits years later, making the core lessons of this report still relevant for teams at any stage of their Kubernetes journey.

Note: Alcide was subsequently acquired by Rapid7 in 2021. Alcide Advisor may no longer be available as a standalone product.