Conform to the Kubernetes restricted pod security standard

[dholbach]

We should make Flux conform to the Kubernetes restricted pod security standard and update the documentation to reflect this.

Patch the deployment spec for:

• source-controller
• kustomize-controller
• helm-controller
• notification-controller
• image-reflector-controller
• image-automation-controller

From Ada Logics

The deployments of the Flux controllers lack container security options that mitigate privilege escalation risks. These are hardening options that we recommend using, and Flux already
makes use of allowPrivilegeEscalation: false on all of its controllers. However, in addition to the allowPrivilegeEscalation option Flux could harden its containers by:

• Dropping all Linux capabilities and enabling those needed
• Filtering syscalls by way of Seccomp

Docker drops many Linux capabilities by default but keeps others for convenience. Flux can harden its containers by having Docker drop all privileges a root user’s process can perform on a system and enabling only those needed. See here for details.

Seccomp filtering is a way of limiting the available system calls and as of v1.19 Kubernetes has support for specifying seccomp policies through the use of seccompProfile in the securityContext of pods. Please see here for details.

Recommendation
Ensure that the pod deployed by Flux has appropriate hardening applied through the use of dropping Linux capabilities and syscall filtering.

[stefanprodan]

We instruct users how to enforce a restricted pod security policy here: https://fluxcd.io/docs/installation/#pod-security-policy

[hiddeco]

That does not align with the recommendation, which is to ship with defaults enabled.

[stefanprodan]

That does not align with the recommendation, which is to ship with defaults enabled.

Yes, shipping a seccomp profile by default is not something that I would consider for Flux. Kubernetes has alpha support for it https://kubernetes.io/blog/2021/08/25/seccomp-default/

[gbstan92]

@stefanprodan the solution above does not cover the registry credentials sync.

Setting the Pod Security Policy in a similar way to the other components causes the following error:

[pjbgf]

@kingdonb you can assign this one to me.

[pjbgf]

Yes, shipping a seccomp profile by default is not something that I would consider for Flux. Kubernetes has alpha support for it https://kubernetes.io/blog/2021/08/25/seccomp-default/

I would agree that we don't want to create and maintain a custom seccomp profile at this point in time. However, enabling the default seccomp profile helps decreasing the impact of potential supply chain attacks.

Seccomp is a bit of a niche subject, but Kubernetes has two separate features for it: one to "enable seccomp across the cluster" (currently in alpha) and the seccomp support itself (GA at version 1.19). We would rely on the latter to comply with some of the recommendations.

The "secure by default" recommendations can be beneficial to the project as a whole, as running in least privileges at all times may help us understand the impact of new features in the security model at earlier stages (i.e. failing tests), and allow us to communicate explicitly as new permission requirements emerge.

I will propose an initial PR for the source-controller and based on feedback I may do the same for the other controllers.

[pjbgf]

@dholbach as part of this we will need to update the documentation around pod security policy. Do you mind adding it here as a check list?

Once all changes are applied we will confirm whether we will be able to support pod-security.kubernetes.io/enforce: restricted, and if so we should also highlight that in the new documentation.

[stefanprodan]

@pjbgf I have added check lists to the issue. Let me know if it covers all tasks.

[pjbgf]

It looks good to me, thank you for updating it. 👍