This article is based on reporting originally published by InfoQ, covering Alcide’s announcement of the sKan tool. Quotes are drawn from an InfoQ interview with Alcide CTO Gadi Naor.
What Is Alcide sKan?
Alcide, a Kubernetes-native security platform, released sKan, a command-line tool designed to give developers, DevOps engineers, and Kubernetes application builders direct access to Alcide’s security analysis capabilities. sKan allows teams to scan Kubernetes configuration and deployment files for security issues as part of their everyday development workflow, including inside CI/CD pipelines.
sKan supports the most common Kubernetes deployment formats:
- Raw Kubernetes resource files (YAML and JSON)
- Helm chart templates
- Kustomized resources
The tool is powered by the same technology used in Alcide Advisor and Open Policy Agent (OPA), making it a production-grade linter for Kubernetes configurations rather than a lightweight syntax checker.
Why Kubernetes Configuration Security Matters
Static application security testing (SAST) and source code scanning are well-established practices. However, Kubernetes introduces an additional attack surface that source code scanners do not cover: the YAML and JSON configuration files that declare how built code runs in a cluster.
Misconfigured Kubernetes resources — such as pods running with excessive privileges, overly broad RBAC permissions, or secrets accidentally embedded in deployment manifests — can introduce serious vulnerabilities into production environments without triggering any source-level security warning.
As Alcide CTO Gadi Naor explained to InfoQ:
Code scanners identify, report, and potentially fix issues found in programming languages. Kubernetes application configurations are effectively YAML/JSON files that declaratively specify how built code will run in Kubernetes. sKan essentially starts where YAML/JSON syntax validation ends.
Gadi Naor, CTO, Alcide
Key Security Checks Performed by sKan
sKan covers multiple security modules, each containing multiple individual checks. At the time of announcement, the modules included:
- Kubernetes Pod Security — verifies pods are not configured to run in privileged mode and checks for worker node risk exposure
- RBAC Privileges — identifies excessive or misconfigured role-based access control permissions
- Misplaced Secrets — detects credentials such as Slack tokens or AWS secret keys accidentally embedded in deployment files
- Service and Ingress Controller checks
- Istio mesh configuration checks
- Prometheus and Etcd operator checks
- Container image registry validation
- Admission controller checks
Naor noted that new modules and checks were planned to ship regularly from both the Alcide team and the broader community.
How Secret Leak Detection Works
sKan scans Kubernetes resources, rendered Helm chart templates, and rendered Kustomized resources against a set of regular expressions to identify secrets that should not be present in configuration files. This is comparable to how GitHub’s secret scanning feature works, but with two important distinctions:
- GitHub’s secret scanners operate on files at rest in a repository. sKan processes resources after Kubernetes-specific transformations (such as Helm rendering or Kustomize overlays), meaning it catches secrets that only appear in the final rendered output.
- sKan points developers to the Kubernetes-specific root cause of the issue, not just the raw file location.
Integrating sKan Into a CI/CD Pipeline
sKan is designed to function as a Kubernetes resource linter inside any pipeline that already uses code linters. According to Naor, developers can:
- Point sKan at an entire directory of Kubernetes resource files
- Render a Helm chart and pipe the output into sKan via standard input
- Pipe Kustomized resources into sKan via standard input
- Use sKan in Git commit hooks to enforce assertions about Kubernetes configuration before code is committed
On the output side, sKan can generate reports in JUnit or HTML format, which can be stored as pipeline artifacts and consumed by downstream tools. For example, CI pipeline logs and artifacts can be exported to platforms such as Splunk, providing auditability and continuous compliance reporting for security teams, architects, and leadership.
sKan as a DevSecOps Tool: Shifting Security Left
sKan is positioned as a practical implementation of the “shift left” principle for Kubernetes security. Rather than discovering configuration vulnerabilities after deployment, sKan surfaces issues during development — before code is committed or promoted through a pipeline.
It complements, rather than replaces, existing source code security scanners. sKan runs alongside language-level SAST tools and adds a layer of Kubernetes-specific analysis that those tools cannot provide.
From a DevOps alignment perspective, sKan helps establish a shared security baseline between development and operations teams. Developers building Kubernetes-based applications can validate security standards locally before handing off components to operations teams responsible for running and maintaining those workloads in production.
Example: Actionable Insights From sKan
Naor provided two concrete examples of risks sKan can detect and the guidance it provides:
1. Secrets Embedded in a Deployment Manifest
If a developer accidentally places a secret — such as a Slack token or AWS secret key — directly inside a Kubernetes resource like a StatefulSet, sKan flags the issue and suggests moving the value to a Kubernetes Secret resource. The recommended best practice is to wire secrets from a dedicated secrets store at application runtime rather than hardcoding them in manifests.
2. Excessive RBAC Permissions on a Cluster Component
If a developer builds a cluster component and grants it broader RBAC permissions than it requires, sKan identifies the over-provisioned permissions as a potential cluster-wide risk. Excessive RBAC grants can allow a compromised workload to affect resources across the entire cluster.
Relationship to Alcide Advisor and Open Policy Agent
sKan uses the same underlying policy engine as Alcide Advisor, Alcide’s broader Kubernetes security advisory product, and leverages Open Policy Agent (OPA) for policy evaluation. This means the checks available via sKan at the CLI level are backed by the same rule sets used in Alcide’s production security platform, rather than a simplified or reduced subset.
Alcide described sKan as a “software translation of DevSecOps culture,” providing developers with a practical mechanism to apply the same policy enforcement used at runtime earlier in the development process.