Top Related Projects
Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
A vulnerability scanner for container images and filesystems
Vulnerability Static Analysis for Containers
Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start
KubeLinter is a static analysis tool that checks Kubernetes YAML files and Helm charts to ensure the applications represented in them adhere to best practices.
Quick Overview
Kubesec is an open-source security risk analysis tool for Kubernetes resources. It scans Kubernetes YAML manifests and Helm charts, providing a risk score and actionable recommendations to improve the security posture of your Kubernetes deployments.
Pros
- Automated security scanning for Kubernetes manifests
- Provides a risk score and detailed recommendations for improvement
- Integrates easily into CI/CD pipelines
- Supports both YAML manifests and Helm charts
Cons
- Limited to static analysis of manifests, not runtime security
- May produce false positives in some scenarios
- Requires regular updates to stay current with evolving Kubernetes security best practices
- Limited customization options for security rules
Getting Started
To use Kubesec, follow these steps:
- Install Kubesec:
curl -s https://github.com/controlplaneio/kubesec/releases/latest/download/kubesec_linux_amd64.tar.gz | tar xz
sudo mv kubesec /usr/local/bin
- Scan a Kubernetes manifest:
kubesec scan /path/to/your/manifest.yaml
- Integrate with CI/CD (example for GitLab CI):
kubesec:
image: docker.io/kubesec/kubesec:v2
script:
- kubesec scan /path/to/your/manifest.yaml
For more advanced usage and integration options, refer to the official Kubesec documentation.
Competitor Comparisons
Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
Pros of Trivy
- Broader scope: Scans containers, filesystems, git repositories, and more
- Faster scanning speed due to efficient caching mechanisms
- More comprehensive vulnerability database, including multiple sources
Cons of Trivy
- Larger resource footprint, potentially slower for small-scale deployments
- More complex setup and configuration compared to Kubesec's simplicity
- May produce more false positives due to its extensive scanning capabilities
Code Comparison
Kubesec example:
kubesec scan deployment.yaml
Trivy example:
trivy image myapp:latest
trivy filesystem /path/to/project
Kubesec focuses specifically on Kubernetes manifests, while Trivy offers a wider range of scanning options. Kubesec's output is typically more concise and focused on Kubernetes-specific security issues, whereas Trivy provides more comprehensive results across various security aspects.
Both tools are valuable for different use cases. Kubesec is ideal for quick Kubernetes manifest checks, while Trivy is better suited for comprehensive security scanning across multiple layers of your application and infrastructure.
A vulnerability scanner for container images and filesystems
Pros of Grype
- Broader scope: Scans for vulnerabilities in container images, filesystems, and packages
- More frequent updates: Active development with regular releases
- Extensive ecosystem integration: Works with various CI/CD tools and container registries
Cons of Grype
- Higher resource usage: May require more system resources for comprehensive scans
- Steeper learning curve: More complex configuration options and output formats
- Less focused on Kubernetes-specific security issues
Code Comparison
Kubesec example:
apiVersion: v1
kind: Pod
metadata:
name: kubesec-demo
spec:
securityContext:
runAsNonRoot: true
Grype example:
grype debian:11 --scope all-layers
Kubesec focuses on analyzing Kubernetes manifests for security best practices, while Grype scans for vulnerabilities in various contexts, including container images. The code examples demonstrate this difference in approach and usage.
Kubesec is more specialized for Kubernetes security auditing, making it easier to use for teams primarily focused on Kubernetes deployments. Grype offers a broader vulnerability scanning capability, making it suitable for diverse environments and use cases beyond Kubernetes.
Both tools have their strengths, and the choice between them depends on the specific security requirements and the scope of the infrastructure being secured.
Vulnerability Static Analysis for Containers
Pros of Clair
- Broader scope: Analyzes vulnerabilities in container images, not just Kubernetes manifests
- More comprehensive: Scans for known vulnerabilities in operating systems and application dependencies
- Integrates with container registries for continuous scanning
Cons of Clair
- More complex setup and maintenance compared to Kubesec
- Requires a database backend for vulnerability data storage
- May have higher resource requirements for large-scale deployments
Code Comparison
Kubesec (YAML manifest analysis):
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example:latest
Clair (Container image analysis):
{
"Layer": {
"Name": "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef",
"Path": "path/to/layer.tar",
"Headers": {
"Docker-Content-Digest": "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
}
}
}
While Kubesec focuses on analyzing Kubernetes YAML manifests for security issues, Clair scans container images for vulnerabilities in the underlying operating system and application dependencies. Kubesec is more lightweight and easier to integrate into CI/CD pipelines for Kubernetes-specific checks, while Clair provides a more comprehensive analysis of container security across different platforms and registries.
Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start
Pros of Dockle
- Focuses specifically on Docker image security and best practices
- Provides a comprehensive set of checks for Dockerfile and image content
- Offers both CLI and CI/CD integration options
Cons of Dockle
- Limited to Docker image analysis, not covering Kubernetes manifests
- May require more setup time for custom rules compared to Kubesec
Code Comparison
Dockle usage:
dockle image_name
Kubesec usage:
kubesec scan kubernetes_manifest.yaml
Key Differences
- Scope: Dockle focuses on Docker images, while Kubesec analyzes Kubernetes manifests
- Output: Dockle provides detailed reports on image issues, whereas Kubesec offers security scores for Kubernetes resources
- Integration: Dockle integrates well with Docker-centric workflows, while Kubesec is more suited for Kubernetes-focused environments
Use Cases
- Choose Dockle for comprehensive Docker image security analysis and best practice checks
- Opt for Kubesec when focusing on Kubernetes manifest security and compliance
Both tools can be valuable in a DevSecOps pipeline, with Dockle ensuring secure Docker images and Kubesec validating Kubernetes configurations.
KubeLinter is a static analysis tool that checks Kubernetes YAML files and Helm charts to ensure the applications represented in them adhere to best practices.
Pros of kube-linter
- More comprehensive set of checks, including security, efficiency, and best practices
- Actively maintained with regular updates and new features
- Supports custom checks and configuration via YAML files
Cons of kube-linter
- Larger codebase and more complex setup compared to kubesec
- May produce more false positives due to its extensive rule set
Code Comparison
kubesec:
func Score(json []byte) ([]byte, error) {
var manifest k8sRuntime.Object
_, gvk, err := scheme.Codecs.UniversalDeserializer().Decode(json, nil, &manifest)
if err != nil {
return nil, err
}
kube-linter:
func (l *GenericLinter) Run(objects []k8sutil.Object) ([]diagnostic.Diagnostic, error) {
var diagnostics []diagnostic.Diagnostic
for _, object := range objects {
if err := l.runChecksOnObject(object, &diagnostics); err != nil {
return nil, err
}
}
Both projects aim to improve Kubernetes security, but kube-linter offers a more comprehensive approach with a wider range of checks. kubesec focuses primarily on security scoring, while kube-linter provides a broader set of linting rules. kube-linter's flexibility and active development make it a strong choice for teams looking for an extensive linting solution, while kubesec might be preferred for its simplicity and focused security scoring.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Kubesec
ð¨ v1 API is deprecated, please read the release notes ð¨
Security risk analysis for Kubernetes resources
Live demo
This uses ControlPlane's hosted API at v2.kubesec.io/scan
- Download Kubesec
- Kubesec HTTP Server
- Kubesec-as-a-Service
- Example output
- Contributors
- Getting Help
- Contributing
- Changelog
Download Kubesec
Kubesec is available as a:
- Docker container image at
docker.io/kubesec/kubesec:v2
- Linux/MacOS/Win binary (get the latest release)
- Kubernetes Admission Controller
- Kubectl plugin
Or install the latest commit from GitHub with:
Go 1.16+
$ go install github.com/controlplaneio/kubesec/v2@latest
Go version < 1.16
$ GO111MODULE="on" go get github.com/controlplaneio/kubesec/v2
Command line usage:
$ kubesec scan k8s-deployment.yaml
Usage example:
$ cat <<EOF > kubesec-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubesec-demo
spec:
containers:
- name: kubesec-demo
image: gcr.io/google-samples/node-hello:1.0
securityContext:
readOnlyRootFilesystem: true
EOF
$ kubesec scan kubesec-test.yaml
Docker usage:
Run the same command in Docker:
$ docker run -i kubesec/kubesec:v2 scan /dev/stdin < kubesec-test.yaml
Specify custom schema
Kubesec leverages kubeconform (thanks @yannh) to validate the manifests to scan. This implies that specifying different schema locations follows the rules as described in the kubeconform README.
Here is a quick overview on how this work for scanning a pod manifest:
- I want to use the latest available schema from upstream.
kubesec [scan|http]
Schema will be fetched from: https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/master-standalone-strict/pod-v1.json
- I want to use a specific schema version from upstream. (Formatted x.y.z with no v prefix)
kubesec [scan|http] --kubernetes-version <version>
Schema will be fetched from: https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/v1.25.3-standalone-strict/pod-v1.json
- I want to use a specific schema version in an airgap environment over HTTP.
kubesec [scan|http] --kubernetes-version <version> --schema-location https://host.server
Schema will be fetched from: https://host.server/v<version>-standalone-strict/pod-v1.json
- I want to use a specific schema version in an airgap environment with local files:
kubesec [scan|http] --kubernetes-version <version> --schema-location /opt/schemas
Schema will be read from: /opt/schemas/v<version>-standalone-strict/pod-v1.json
Note: in order to limit external network calls and allow usage in airgap
environments, the kubesec
image embeds schemas. If you are looking to change
the schema location, you'll need to change the K8S_SCHEMA_VER
and SCHEMA_LOCATION
environment variables at runtime.
Print the scanning rules with their associated scores
All the scanning rules can be printed in in different formats (json (default), yaml and table). This is useful to easily get the point associated with each rule:
kubesec print-rules
which produces the following output:
[
{
"id": "AllowPrivilegeEscalation",
"selector": "containers[] .securityContext .allowPrivilegeEscalation == true",
"reason": "Ensure a non-root process can not gain more privileges",
"kinds": [
"Pod",
"Deployment",
"StatefulSet",
"DaemonSet"
],
"points": -7,
"advise": 0
},
...
]
Kubesec HTTP Server
Kubesec includes a bundled HTTP server
The listen address for the HTTP server can be configured by setting
KUBESEC_ADDR
environment variable. The value can be a single port
such as 8080
or an address in the form of ip:port
or [ipv6]:port
.
CLI usage example:
Start the HTTP server in the background
$ kubesec http 8080 &
[1] 12345
{"severity":"info","timestamp":"2019-05-12T11:58:34.662+0100","caller":"server/server.go:69","message":"Starting HTTP server on port 8080"}
Use curl to POST a file to the server
$ curl -sSX POST --data-binary @test/asset/score-0-cap-sys-admin.yml http://localhost:8080/scan
[
{
"object": "Pod/security-context-demo.default",
"valid": true,
"message": "Failed with a score of -30 points",
"score": -30,
"scoring": {
"critical": [
{
"selector": "containers[] .securityContext .capabilities .add == SYS_ADMIN",
"reason": "CAP_SYS_ADMIN is the most privileged capability and should always be avoided",
"points": -30
},
{
"selector": "containers[] .securityContext .runAsNonRoot == true",
"reason": "Force the running image to run as a non-root user to ensure least privilege",
"points": 1
},
// ...
Finally, stop the Kubesec server by killing the background process
$ kill %
Docker usage example:
Start the HTTP server using Docker
$ docker run -d -p 8080:8080 kubesec/kubesec:v2 http 8080
Use curl to POST a file to the server
$ curl -sSX POST --data-binary @test/asset/score-0-cap-sys-admin.yml http://localhost:8080/scan
...
Don't forget to stop the server.
Kubesec-as-a-Service
Kubesec is also available via HTTPS at v2.kubesec.io/scan
Please do not submit sensitive YAML to this service.
The service is ran on a good faith best effort basis.
Command line usage:
$ curl -sSX POST --data-binary @"k8s-deployment.yaml" https://v2.kubesec.io/scan
Usage example:
Define a BASH function
$ kubesec ()
{
local FILE="${1:-}";
[[ ! -e "${FILE}" ]] && {
echo "kubesec: ${FILE}: No such file" >&2;
return 1
};
curl --silent \
--compressed \
--connect-timeout 5 \
-sSX POST \
--data-binary=@"${FILE}" \
https://v2.kubesec.io/scan
}
POST a Kubernetes resource to v2.kubesec.io/scan
$ kubesec ./deployment.yml
Return non-zero status code is the score is not greater than 10
$ kubesec ./score-9-deployment.yml | jq --exit-status '.score > 10' >/dev/null
# status code 1
Example output
Kubesec returns a returns a JSON array, and can scan multiple YAML documents in a single input file.
[
{
"object": "Pod/security-context-demo.default",
"valid": true,
"message": "Failed with a score of -30 points",
"score": -30,
"scoring": {
"critical": [
{
"selector": "containers[] .securityContext .capabilities .add == SYS_ADMIN",
"reason": "CAP_SYS_ADMIN is the most privileged capability and should always be avoided",
"points": -30
}
],
"advise": [
{
"selector": "containers[] .securityContext .runAsNonRoot == true",
"reason": "Force the running image to run as a non-root user to ensure least privilege",
"points": 1
},
{
// ...
}
]
}
}
]
Contributors
Thanks to our awesome contributors!
Getting Help
If you have any questions about Kubesec and Kubernetes security:
- Read the Kubesec docs
- Reach out on Twitter to @sublimino or @controlplaneio
- File an issue
Your feedback is always welcome!
Top Related Projects
Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
A vulnerability scanner for container images and filesystems
Vulnerability Static Analysis for Containers
Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start
KubeLinter is a static analysis tool that checks Kubernetes YAML files and Helm charts to ensure the applications represented in them adhere to best practices.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot