feat: Add custom section for corporate CA Certificate in falco chart as requested in feature request #3907

[heitzflorian]

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?
/area chart

What this PR does / why we need it:

At the moment mounts.volumes, falcoctl.artifact.install.mounts and falcoctl.artifact.follow.mounts sections already exists in the falco upstream chart, but no extra section to declare the secret object in which you put the CACert content in.

Having an optional setting in the extra section in which we can provide a custom corporate CA certificate used by the target registry falcoctl is interacting with can help on-premise customized deployment to work out of the box after helm install command without manual post-install actions.

Which issue(s) this PR fixes:

Fixes #3907

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: heitzflorian
Once this PR has been reviewed and has the lgtm label, please assign mstemm for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[poiana]

Welcome @heitzflorian! It looks like this is your first PR to falcosecurity/falco 🎉

[kunalworldwide]

A couple of things I noticed reviewing the Helm template changes:

1. data vs stringData in the Secret template

falcoctl-cacert-secret.yaml puts the PEM certificate under data:, but Kubernetes data fields require base64-encoded values. Since toYaml outputs the raw PEM string, this will either fail to create the Secret or produce a garbled certificate. You probably want stringData: instead, which accepts plain text and handles the encoding automatically:

stringData:
  registry-cacert.pem: |-
    {{- toYaml .Values.extra.registryCustomCaCert.cacert | nindent 4 }}

2. Mount path shadows system certs

The example in values.yaml mounts the volume at /etc/ssl/certs, which would replace the container's entire system certificate directory. That means falcoctl loses access to all public CAs. A subPath mount or a path like /etc/ssl/certs/custom-ca.pem would be safer — lets the custom CA coexist with the system trust store.

3. Minor: missing trailing newline

falcoctl-cacert-secret.yaml is missing a trailing newline at EOF.

Overall the approach makes sense. The data/stringData fix is the main blocker.

[heitzflorian]

A couple of things I noticed reviewing the Helm template changes:

1. data vs stringData in the Secret template

falcoctl-cacert-secret.yaml puts the PEM certificate under data:, but Kubernetes data fields require base64-encoded values. Since toYaml outputs the raw PEM string, this will either fail to create the Secret or produce a garbled certificate. You probably want stringData: instead, which accepts plain text and handles the encoding automatically:

stringData:
  registry-cacert.pem: |-
    {{- toYaml .Values.extra.registryCustomCaCert.cacert | nindent 4 }}

2. Mount path shadows system certs

The example in values.yaml mounts the volume at /etc/ssl/certs, which would replace the container's entire system certificate directory. That means falcoctl loses access to all public CAs. A subPath mount or a path like /etc/ssl/certs/custom-ca.pem would be safer — lets the custom CA coexist with the system trust store.

3. Minor: missing trailing newline

falcoctl-cacert-secret.yaml is missing a trailing newline at EOF.

Overall the approach makes sense. The data/stringData fix is the main blocker.

Hi @kunalworldwide and thanks for your reply.

• I definitely have to check my IDE because it's not the first time i have som EOL issues.
• You're definitely right regarding the mount overlapping existing CACerts: i'll make modifications to use subPath.
• You're right again regarding the use of data VS stringData even if i have some security concerns regarding the use of stringData (see later in post): it can't work with actual code by the way.

I either have to chose between using stringData which is easier, or find a way to base64encode prior piping it to toYaml | nindent 4.

What may have bothered me with stringData, is that by default the clear version ends up in the last-applied-configuration annotation (is it expected or should i raise a security issue to kubernetes community ?), which is not the case with the use of data.

stringData example:

$ cat stringData-secret.yml
apiVersion: v1
kind: Secret
metadata:
  name: dummysecret
type: Opaque
stringData:
  my-secret: "clearValue"

$ kubectl apply -f stringData-secret.yml
secret/dummysecret created

$ kubectl get secrets dummysecret -o yaml
apiVersion: v1
data:
  my-secret: Y2xlYXJWYWx1ZQ==
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"dummysecret","namespace":"default"},"stringData":{"my-secret":"clearValue"},"type":"Opaque"}
  creationTimestamp: "2026-06-25T16:03:10Z"
  name: dummysecret
  namespace: default
  resourceVersion: "22296700"
  uid: 5822068f-afe9-48fd-ab80-7035fd59c196
type: Opaque

As you can see, in the kubectl.kubernetes.io/last-applied-configuration annotation of the secret object, we can find the clear value under stringData":{"my-secret":"clearValue"}, which is some kind of data disclosure (of course, we know that base64 is however reversible, but plaintext/cleartext seems even worth to me).

data example:

$ cat data-secret.yml
apiVersion: v1
kind: Secret
metadata:
  name: dummysecret2
type: Opaque
data:
  my-secret: Y2xlYXJWYWx1ZQ==

$ kubectl apply -f data-secret.yml
secret/dummysecret2 created

$ kubectl get secrets dummysecret2 -o yaml
apiVersion: v1
data:
  my-secret: Y2xlYXJWYWx1ZQ==
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"my-secret":"Y2xlYXJWYWx1ZQ=="},"kind":"Secret","metadata":{"annotations":{},"name":"dummysecret2","namespace":"default"},"type":"Opaque"}
  creationTimestamp: "2026-06-25T16:06:58Z"
  name: dummysecret2
  namespace: default
  resourceVersion: "22298068"
  uid: cd207bf0-7d75-4fe6-a95c-97faec317d87
type: Opaque

In the case of data, the version stored in kubectl.kubernetes.io/last-applied-configuration annotation is base64 encoded as well.

I'll check if i have any way to base64 encode the content before chaining with toYaml | nindent 4, but if i don't succeed i will choose the stringData way.

I'll let you know and update my PR in any case.

[poiana]

Adding label do-not-merge/contains-merge-commits because PR contains merge commits, which are not allowed in this repository.
Use git rebase to reapply your commits on top of the target branch. Detailed instructions for doing so can be found here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kunalworldwide]

Thanks for adding this — custom CA certs for corporate registries are a real gap in the chart.

I reviewed the Secret template and I think there is a base64 encoding issue:

• chart/falco/templates/falcoctl-cacert-secret.yaml uses data: and stores the raw PEM string under registry-cacert.pem. Kubernetes data fields must be base64-encoded, so a raw PEM value will render as invalid base64 and the Pod will not be able to mount it.
• The fix is to switch to stringData: (which Kubernetes encodes automatically) or to base64-encode the value in the template. Given that users are already pasting PEM text in values, stringData: is the safer UX.

A couple of other small things:

1. The docs example mounts to /etc/ssl/certs. That shadows the entire system certificate directory inside the falcoctl container. If the image already has distro CAs there, they will be hidden. Consider using subPath: registry-cacert.pem and mounting to a specific file path (e.g. /etc/ssl/certs/registry-cacert.pem) so the base image CAs remain visible.
2. The volume name {{ include "falco.fullname" . }}-falcoctl-registry-cacert-volume could exceed 63 characters for long release names. Helm chart helpers usually do not truncate falco.fullname, so this is worth clamping or using a shorter static suffix.
3. The new template file is missing a trailing newline.
4. There are no chart tests for the new Secret/volume. Even a simple helm template render test with registryCustomCaCert.enabled=true would catch the data vs stringData issue.

Happy to re-review once the Secret encoding is fixed.