Flux source controller artefacts without authentication within the cluster

[morancj]

Report

This section to be completed to report a potential vulnerability.

Describe

Reported by guillaume.berche@orange.com.

I’m reporting a suspected security issue as suggested into https://docs.gitops.weave.works/security/

I’ve been observing that following a flux installation with the openshift OLM installation, the source controller artefacts are available without authentication and without encryption within the whole cluster. As a flux user, I believe this is an insecure security default. Even though git repos are not supposed to include unencrypted secrets, exposing source controllers artefacts without authentication or in-transient (tls) encryption causes the following security issues:

A malicious container within a multi tenant openshift cluster may be discover the list of git repo names available in source controllers Then laterally download source artefacts and access confidential information such as how the current cluster is provisioned or secured using flux. Then Search for any non encrypted secret in the artefacts

The https://artifacthub.io/packages/olm/community-operators/flux does not seem to provide sufficient warning or guidance related to built-in security

Also the source controller seems to help with the discovery of the available artefacts

root@debug-tool-2qj4b:~# curl -vvv http://source-controller.flux-system.svc.cluster.local./gitrepository/fluxcd/
*   Trying 172.30.150.238...
* TCP_NODELAY set
* Connected to source-controller.flux-system.svc.cluster.local (172.30.150.238) port 80 (#0)
GET /gitrepository/fluxcd/ HTTP/1.1
Host: source-controller.flux-system.svc.cluster.local
User-Agent: curl/7.58.0
Accept: */*

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Last-Modified: Thu, 19 Jan 2023 10:46:39 GMT
Date: Mon, 23 Jan 2023 09:40:01 GMT
Content-Length: 129

<pre>
<a href="paas-k8s-config-repo/">paas-k8s-config-repo/</a>
<a href="paas-k8s-gitops-repo/">paas-k8s-gitops-repo/</a>
</pre>

References

Post to security@weave.works Weaveworks security vulnerability process

Handling

If you are reporting a potential vulnerability, you could ignore this section. It is intended to be managed by a Vulnerability Manager

• [x] Reporter notifies Weaveworks team (Receiver) about a potential vulnerability via any of the Security Vulnerability Sources. Receiver acknowledges it. If likely to be a legitimate request, Receiver creates a private issue of type CVE in https://github.com/weaveworks/weave-gitops-private to start the formal intake.
• [x] Vulnerability Manager triages the request to either accept or rejects it:
• [x] In case of accepted, Vulnerability Manager starts the coordination of the vulnerability based on the created issue. The vulnerability is treated as highest priority and directed to the respective Product Team.
• [ ] In case of rejected, if needed, a response to Reporter is provided about the rejection and the process terminates.
• [x] Product Team evaluates the vulnerability with help from Vulnerability Manager. The evaluation should include which products and versions are affected.
• [x] If the vulnerability does not pose a threat to the product or service, Vulnerability Manager responds back to the Reporter with proper reasoning.
• [ ] If the reported request is considered a vulnerability, Vulnerability Manager responds back to the Reporter, accepting the issue. Vulnerability Manager communicates and coordinates to the rest of internal stakeholders. Vulnerability Manager engages with CX to start the discovery of customers being affected.
• [ ] Product team provides a workaround, Vulnerability Manager makes it available to the Reporter and notifies CX. CX manages with customers the workaround.
• [ ] Product Team works to identify a fix and produce a time estimation (ETA) to create the fix for the product or service.
• [ ] Vulnerability Manager adds a 4 weeks buffer to the ETA. This date becomes the public announcement date.
• [ ] Vulnerability Manager e notifies the Reporter of the public announcement date. Vulnerability Manager asks the Reporter if they want to be credited. A Public Security Advisory will be issued accordingly.
• [ ] Vulnerability Manager creates a Private Security Advisory for the vulnerability, including the impact, and any available mitigations. It would be created using this template. An example of a Security Advisory is CVE-1126.
• [ ] CX would announce with customers the vulnerability sharing the Security Advisory.
• [ ] Product Team delivers the fix and communicates to Vulnerability Manager. Vulnerability Manager provides it to the Reporter and all affected customers via CX. CX manages the application of the fix on the customer side.
• [ ] A Public Security Advisory will be issued after all the fixes are issued to the customers and the public announcement date has been reached.

[lizwarner-weave]

I will be temporary Vunerability Manager until we agree which group owns the fix to this issue (or if indeed we intend to fix anything). Discussion history is on the flux channel, much of 27 Jan 2023.

[lizwarner-weave]

Resolution WIP https://github.com/weaveworks/flux2-openshift/pull/18

Assigning to Soule as Vulnerability Manager

[souleb]

Operatorhub has been updated with the lastest flux version(v0.40.0). We have updated the description with a warning stating that the Network policies are not shipped with the bundle. See https://operatorhub.io/operator/flux.

However we have tested that manually applying the Network Policies on openshift works fine.

Closing this now.