Skip to content

feat: add IaC security scanning with Checkov#6

Open
moghit-eou wants to merge 4 commits intoMedical-Informatics-Platform:mainfrom
moghit-eou:feat/iac-scanning-checkov
Open

feat: add IaC security scanning with Checkov#6
moghit-eou wants to merge 4 commits intoMedical-Informatics-Platform:mainfrom
moghit-eou:feat/iac-scanning-checkov

Conversation

@moghit-eou
Copy link
Copy Markdown
Contributor

@moghit-eou moghit-eou commented Mar 20, 2026

What this does

Adds a Checkov workflow that scans all Kubernetes, Helm, and Kustomize
files on every PR for security misconfigurations.

Known limitation ( security gap ): skip_check

CKV_K8S_8, CKV_K8S_9, CKV_K8S_35 are globally skipped to avoid false positives on ArgoCD
which are not Kubernetes workloads and have no containers. You can find all the Checkov's rules in this link

I'm still working through the codebase to identify exactly which ArgoCD files need to be modified and I will address this in a follow up PR.

soft_fail: true

mip-infra has never been scanned before that why the first run will surface existing
findings in current files. soft_fail=true makes issues visible without
blocking all open PRs immediately.

  • To be removed once existing findings are resolved.
image

@github-advanced-security
Copy link
Copy Markdown

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

  • The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
  • Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
  • You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

@jdaln
Copy link
Copy Markdown
Contributor

jdaln commented Mar 20, 2026

Nice PR, thank you again @moghit-eou .
If that's ok with you, I will process it next week when I get some time in the middle of Kubecon. I want to look into the rules that were excluded for example. Looks totally good from what I see but I want to do a real review.

@jdaln
Copy link
Copy Markdown
Contributor

jdaln commented Mar 30, 2026

Hi @moghit-eou,
Sorry for taking so much time. The conference was busier than expected.
Most of the failures right now are on a part that is deemed to be removed in the next days, if everything goes well, when we do a version upgrade.
submariner-io/submariner-charts#695

Now for the following, what was the logic behind excluding them fully? Is there an option for exceptions instead maybe?

  • CKV_K8S_35: Prefer using secrets as files over secrets as environment variables
  • CKV_K8S_8: Liveness probes should be configured
  • CKV_K8S_9: Readiness Probe Should be Configured

Finally, Checkov now only scans this repo and not the dependencies it pulls. While this is a simple approach that can be remediated by adding checkov to other MIP repositories, what happens for other dependencies? I have to say that I don't yet have a solution for this but this is something we will need to think about and that is not blocking for this PR>

@moghit-eou
Copy link
Copy Markdown
Contributor Author

Hi @jdaln,

Hope the conference went well.

On the Submariner failures: thanks for the context, good to know those should be cleaned up with the version upgrade.

On the global skips: My initial approach was too broad. I used those three skips as a temporary way to unblock the first scan, but I intended to narrow them down properly.

After a quick reviewing the repo and the relevant Checkov references, here is what I found:

CKV_K8S_8 / CKV_K8S_9 are workload checks for liveness and readiness probes. In this repo, they are not meaningful on ArgoCD control resources such as ApplicationSet and AppProject, since those objects do not define runtime containers. There is also a confirmed Checkov false-positive issue for these checks on init containers, which cannot have probes by Kubernetes design (CKV_K8S_8 & CKV_K8S_9 false positives#4807).

CKV_K8S_35 is also a workload-level check: it evaluates how running containers consume secrets. For the same reason, it is not meaningful on ArgoCD control resources that do not define runtime containers or environment-variable based secret injection. The full scope of what this check targets is documented in the Checkov Kubernetes policy index.

On exceptions instead of global skips: Checkov supports inline suppression at the individual resource level (suppression docs), so my proposed fix is to remove the global skip_check from the workflow and add targeted inline comments only on the ArgoCD resource files where these workload checks do not apply.
( This is just an example , not sure yet exactly how it will be implemented )

# checkov:skip=CKV_K8S_8: ArgoCD control resource - no runtime containers defined
# checkov:skip=CKV_K8S_9: ArgoCD control resource - no runtime containers defined
# checkov:skip=CKV_K8S_35: ArgoCD control resource - no runtime containers defined
apiVersion: argoproj.io/v1alpha1
kind: Application
...

This way, real workload manifests such as common/nginx-ingress/manifests/nginx-public-deployment.yaml remain fully checked without broad exceptions.

On dependency scanning: you are right that Checkov currently only scans this repository, not the external Helm charts it references. I agree that is a separate gap worth tracking, and adding checks upstream in the MIP-related repositories seems like the cleanest direction.

Does that approach make sense?

Sorry, I can't provide more detailed approach I have an university exam this week so I have not had the chance to fully work through the implementation yet but I will take a closer look once that is done and update the PR in the weekend.

@jdaln
Copy link
Copy Markdown
Contributor

jdaln commented Mar 31, 2026

@moghit-eou it did, thank you! And I have some takeaways in terms of runtime security that will be interesting to look at I believe :) .

This approach is excellent. Let's wait for Google to communicate the results for the GSoC at the end of the month before moving further for now I would say. Good luck for your exams!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants