rfc: Add build-in TLS support draft

Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>

rfcs/0000-build-in-tls-support/README.md

@@ -0,0 +1,137 @@
+# RFC-NNNN Built-in TLS support for Source and Notification Controllers
+
+**Status:** provisional
+
+**Creation date:** 2022-12-05
+
+**Last update:** 2022-12-05
+
+## Summary
+
+Create built-in TLS support for both Source and Notification controllers,
+so that in-cluster cross-component communications are always encrypted.
+
+## Motivation
+
+Due to internal company policies, Data Protection laws and regulations,
+Flux users may be required to enforce encryption of data whilst in-transit.
+As of `v0.37.0`, there is no built-in way to provide TLS for Flux' endpoints.
+
+The existing endpoints being:
+
+1. Source Controller: artifacts storage, used by Kustomize and HelmRelease
+controllers.
+2. Notification Controller: events receivers, used by all other Flux components
+to submit events.
+3. Notification Controller: webhooks for external services to contact Flux.
+
+The webhooks endpoing would be typically used for external use only, and in
+that use case the recommended approach is to enable TLS at ingress.
+However, this proposal covers the first two endpoints to allow always encrypted
+in-cluster communications.
+
+### Goals
+
+- Add TLS support for Notification and Source controllers.
+- Establish a migration process when enabling TLS on existing clusters.
+- Define best practices on enabling the feature.
+
+### Non-Goals
+
+- Change how CA trust is established across Flux containers.
+- Define TLS rotation mechanisms.
+
+## Proposal
+
+Controllers hosting web servers will introduce a new flag to configure the
+[TLS secret]: `--tls-secret`. The Secret type must be `kubernetes.io/tls`.
+
+Invalid secret types, or content, will cause the controller to fail to start.
+
+### Source Controller
+
+When TLS is enabled, the File Storage endpoint will serve both HTTP and HTTPS.
+Existing source objects previously reconciled won't be patched to a new
+`.status.artifact.url`, but all new reconciliations will cause that field to
+start with `https://`.
+
+The HTTP endpoint will only serve a permanent redirect (301) to the HTTPS endpoint,
+enabling a smooth transition when users enable this feature in existing clusters.
+
+The HTTPS endpoint will be served on port `9443` by default, which will be
+configurable via new flag `--storage-https-addr` or environment variable
+`STORAGE_HTTPS_ADDR`. The existing `source-controller` service will bind port
+`443` to `9443`.
+
+### Notification Controller
+
+When TLS is enabled, the HTTP endpoints will be disabled.
+
+#### Events endpoint
+
+The events HTTPS endpoint will be served on port `9443` by default, which will be
+configurable via new flag `--events-https-addr`. The existing `notification-controller`
+service will bind port `443` to `9443`.
+
+All flux components will need to be started with the (existing) flag below, for the
+TLS only endpoint to be used:
+`--events-addr=https://notification-controller.flux-system.svc.cluster.local./`
+
+### User Stories
+
+<!--
+Optional if existing discussions and/or issues are linked in the motivation section.
+-->
+
+### Alternatives
+
+#### Delegate in-trasit data encryption to CNI or Service Mesh
+
+Instead of built-in support, it was considered the option of delegating this to
+external components that support the enablement of end-to-end encryption via TLS
+or mTLS. One of the issues with this approach is that the data would still come
+out of Flux unencrypted, and therefore privileged co-located components in the
+same worker node could be privy to the exchanged plain-text.
+
+Another point considered for not pursuing this alternative was that, being one of
+the first workloads inside a cluster, Flux should be self-reliant in assuring the
+confidentiality and integrity of its communications.
+
+#### Auto-detection of TLS events endpoint
+
+Instead of having to change the `--event-addr` on each Flux component, an auto
+detection mechanism could be implemented to prefer the TLS endpoint whenever the
+notification controller's service has one working.
+
+The challenge with such approach is that the security of cross component
+communication would be non deterministic from a client perspective, and would depend
+on the Notification controller having an active TLS endpoint at the time in which each
+Flux component started. The current approach requires additional configuration,
+but fails safe.
+
+## Design Details
+
+### TLS Versions and Ciphers Supported
+
+For reduced complexity and increased security, only TLS 1.3 is supported.
+
+### Detect TLS Certificate changes
+
+Controllers will watch the TLS secret for changes, once detected it will trigger a
+pod restart to refresh the certificates being used.
+
+### Expand TLS support for the webhooks endpoint
+
+The TLS support could be expanded to the Notification controller webhooks endpoint
+to enable secure in-cluster communications.
+
+## Implementation History
+
+<!--
+Major milestones in the lifecycle of the RFC such as:
+- The first Flux release where an initial version of the RFC was available.
+- The version of Flux where the RFC graduated to general availability.
+- The version of Flux where the RFC was retired or superseded.
+-->
+
+[TLS secret]: https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets