Open ferrarimarco opened 5 months ago
Hi @ferrarimarco , thank you for reaching out.
The kubernetes framework reports some failures against the files that we customize with Kustomize, as expected, because Kustomize didn't run
I'm not sure I understand the issue. Seems like you have the expected result. Do you mind elaborating?
Hi @Saarett !
The issue is that we cannot run Checkov against the whole repository in a single run, or at least we didn't find a way to do that:
all
?):
kubernetes
framework: "bare" Kubernetes descriptors passes (OK)kubernetes
framework: Kubernetes descriptors that we customize with Kustomize fail (not OK)kustomize
framework:
kubernetes
framework: "bare" Kubernetes descriptors skipped (not OK)kubernetes
framework: Kubernetes descriptors that we customize with Kustomize skipped (not OK)kubernetes
framework:
kubernetes
framework: "bare" Kubernetes descriptors passes (OK)kubernetes
framework: Kubernetes descriptors that we customize with Kustomize fail (not OK)That's why I was wondering if there was a way to skip a check only for a given framework. This way, we could avoid specifying any framework, and run Checkov once against the whole repository, and get:
kubernetes
framework: "bare" Kubernetes descriptors passes (OK)kubernetes
framework: skip the checks that we handle with Kustomize customization (OK)Hopefully this helps!
@ferrarimarco Do you mind sharing a short example that can be reproduced?
Sure!
/test/linters/checkov/good/good_kustomize/graph_check.yaml
-> Passes with the kubernetes
framework
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: internal-proxy-deployment
labels:
app: internal-proxy
spec:
selector:
matchLabels:
app: internal-proxy
template:
metadata:
labels:
app: internal-proxy
spec:
containers:
- name: internal-api
image: test-image
resources:
limits:
cpu: 30m
memory: 40Mi
requests:
cpu: 30m
memory: 40Mi
ports:
- containerPort: 3000
...
/test/linters/checkov/good/good_kustomize/kustomization.yaml
:
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:
- name: test-image
newName: hello-world
newTag: linux
digest: sha256:b7d87b72c676fe7b704572ebdfdf080f112f7a4c68fb77055d475e42ebc3686f
namespace: non-default-namespace
resources:
- graph_check.yaml
...
test/linters/kubernetes_kubeconform/kubeconform_good_1.yaml
-> Passes with the kustomize
framework, fails with the kubernetes
framework. (expected)
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 4
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.13.12
ports:
- containerPort: 80
We get the following violations:
kubernetes scan results:
Passed checks: 0, Failed checks: 3, Skipped checks: 0
Check: CKV_K8S_43: \"Image should use digest\"
FAILED for resource: Deployment.default.internal-proxy-deployment
File: /test/linters/checkov/good/good_kustomize/graph_check.yaml:2-44
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/kubernetes-policies/kubernetes-policy-index/bc-k8s-20
[...]
Check: CKV_K8S_43: "Image should use digest"
FAILED for resource: Deployment.default.internal-proxy-deployment
File: /test/linters/checkov/good/good_kustomize/graph_check.yaml:2-44
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/kubernetes-policies/kubernetes-policy-index/bc-k8s-39
[...]
Check: CKV_K8S_14: "Image Tag should be fixed - not latest or blank"
FAILED for resource: Deployment.default.internal-proxy-deployment
File: /test/linters/checkov/good/good_kustomize/graph_check.yaml:2-44
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/kubernetes-policies/kubernetes-policy-index/bc-k8s-13
This is expected because the kubernetes
framework didn't run Kustomize. To avoid these failures, we could either:
kubernetes
framework: we want to keep it because we have Kubernetes descriptors that we want to lint that don't need Kustomize (or Helm).kubernetes
framework against the bare Kubernetes descriptors only, run the kustomize
framework against Kustomize stuff... This is linkely not a scalable solution, tho.Is there a way we can run all the frameworks against the whole repository in a single Checkov run?
Thanks!
PS: I updated my previous post to clarify the second case because I was missing a couple of sentences, although the meaning could be deducted from the context.
PS: after looking at the current list or frameworks, this seems to apply to frameworks that use the very same set of policies, but can have different results when checking the same set of files, such as the kubernetes
, helm
, and kustomize
frameworks. (terraform
and terraform plan
maybe have the same issue?)
I think the main issue is probably that these frameworks are using the same policies (or at least with the same policy ID), so, for example, I can't exclude CKV_K8S_43
for the kubernetes
framework, and keep it for the kustomize
framework. This design decision seems to imply that the kubernetes
, kustomize
, and helm
frameworks are considered to be mutually exclusive.
@gruebel By any chance do you remember the behaviour, before I dive into the code?
CC @tsmithv11
Describe the issue
Hi! In our repository, we have two directories:
We're running Checkov as follows:
checkov --config-file /path-to-config-file/.checkov.yaml
The config file is quite simple:
kustomize
is available in thePATH
, so we see thekustomize
framework checks passing as expected.Given that we don't specify any framework, Checkov also runs the
kubernetes
framework. Thekubernetes
framework reports some failures against the files that we customize with Kustomize, as expected, because Kustomize didn't run.Is there a way we can configure Checkov to handle this use case without having to configure the specific frameworks we want to run?
Examples
https://github.com/super-linter/super-linter/pull/5763
Version (please complete the following information):
3.2.125
Additional context
The skipping mechanism and the baseline mechanism don't seem to take into account the framework.