From 1d8105247a5b5b10928378117e377d73a92a3cd9 Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Thu, 8 Sep 2022 09:54:21 +0530 Subject: [PATCH 1/9] add RFC for blocking insecure HTTP connections across Flux Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 91 +++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 rfcs/0004-insecure-http/README.md diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md new file mode 100644 index 00000000..73bc2058 --- /dev/null +++ b/rfcs/0004-insecure-http/README.md @@ -0,0 +1,91 @@ +# RFC-0004 Block insecure HTTP connections across Flux + +**Status:** provisional + +**Creation Date:** 2022-09-08 + +## Summary +Flux should have a consistent way of disabling insecure HTTP connections. + +At the controller level, a flag should be present which would disable all outgoing HTTP connections. +At the object level, a field should be provided which would enable the use of non-TLS endpoints. + +If the use of a non-TLS endpoint is not supported, it should be made clear to users through the use of +logs and status conditions. + +## Motivation +Today the use of non-TLS based connections is inconsistent across Flux controllers. + +Controllers that deal only with `http` and `https` schemes have no way to block use of the `http` scheme at controller-level. +Some Flux objects provide a `.spec.insecure` field to enable the use of non-TLS based endpoints, but they don't clearly notify users when the option is not supported (e.g. Azure/GCP Buckets). + +### Goals +* Provide a flag across all Flux controllers which disables all outgoing HTTP connections. +* Add a field which enables the use of non-TLS endpoints to appropriate Flux objects. +* Provide a way for users to be made aware that their use of non-TLS endpoints is not supported if that is the case. + +### Non-Goals +* Break Flux's current behavior of allowing HTTP connections. + +## Proposal + +### Controllers +Flux users should be able to enforce that controllers are using HTTPS connections only. +This shall be enabled by adding a new boolean flag `--allow-insecure-http` to the following controllers: +* source-controller +* notification-controller +* image-automation-controller +* image-reflector-controller + +> Note: The flag shall not be added to the following controllers: +> * kustomize-controller: This flag is excluded from this controller, as the upstream `kubenetes-sigs/kustomize` project +> does not support disabling HTTP connections while fetching resources from remote bases. We can revisit this if the +> upstream project adds support for this at a later point in time. +> * helm-controller: This flag does not serve a purpose in this controller, as the controller does not make any HTTP calls. +> Furthermore although both controllers can also do remote applies, serving `kube-apiserver` over plain +> HTTP is disabled by default. While technically this can be enabled, the option for this configuration was also disabled +> quite a while back (ref: https://github.com/kubernetes/kubernetes/pull/65830/). + +The default value of this flag shall be `true`. This would ensure that there is no breaking change with controllers +still being able to access non-TLS endpoints. To disable this behavior and enforce the use of HTTPS connections, users would +have to explicitly pass the flag to the controller: + +```yaml +spec: + template: + spec: + containers: + - name: manager + image: fluxcd/source-controller + args: + - --watch-all-namespaces + - --log-level=info + - --log-encoding=json + - --enable-leader-election + - --storage-path=/data + - --storage-adv-addr=source-controller.$(RUNTIME_NAMESPACE).svc.cluster.local. + - --allow-insecure-http=false +``` + +### Objects +Some Flux objects, like `GitRepository`, provide a field for specifying a URL, and the URL would contain the scheme. +In such cases, the scheme can be used for inferring the transport type of the connection and consequently, +whether to use HTTP or HTTPS connections for that object. +But there are a few objects that don't allow such behavior, for example: + +* `ImageRepository`: It provides a field, `.spec.image`, which is used for specifying the URL of the image present on +a container registry. But any URL containing a scheme is considered invalid and HTTPS is the default transport used. +This prevents users from using images present on insecure registries. +* OCI `HelmRepository`: When using an OCI registry as a Helm repository, the `.spec.url` is expected to begin with `oci://`. +Since the scheme part of the URL is used to specify the type of `HelmRepository`, there is no way for users to specify +that the registry is hosted at a non-TLS endpoint. + +For such objects, we shall introduce a new boolean field `.spec.insecure`, which shall be `false` by default. Users that +need their object to point to an HTTP endpoint, can set this to `true`. + +### Precedence & Validity +Objects with `.spec.insecure` as `true ` will only be allowed if HTTP connections are allowed at the controller level. +Similarly, an object can have `.spec.insecure` as `true` only if the Saas/Cloud provider allows HTTP connections. +For example, using a `Bucket` with its `.spec.provider` set to `azure` would be invalid since Azure doesn't allow +HTTP connections. + From d2e7a37eb4040be1c8e67640958dadc892197384 Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Thu, 8 Sep 2022 09:54:52 +0530 Subject: [PATCH 2/9] add user stories and alternatives for insecure HTTP RFC Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 47 +++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 73bc2058..5f463ab4 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -89,3 +89,50 @@ Similarly, an object can have `.spec.insecure` as `true` only if the Saas/Cloud For example, using a `Bucket` with its `.spec.provider` set to `azure` would be invalid since Azure doesn't allow HTTP connections. + +### User Stories + +#### Story 1 +> As a cluster admin of a multi-tenant cluster, I want to ensure all controllers access endpoints using only HTTPS +> regardless of tenants' object definitions. + +Apply a `kustomize` patch which prevents the use of HTTP connections: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --allow-insecure-http=false + target: + kind: Deployment + name: "(kustomize-controller|helm-controller|source-controller|notification-controller)" +``` + +#### Story 2 +> As an application developer, I'm trying to debug a new image pushed to my local registry which +> is not served over HTTPS. + +Modify the object spec to use HTTP connections explicitly: +```yaml +apiVersion: image.toolkit.fluxcd.io/v1beta1 +kind: ImageRepository +metadata: + name: podinfo + namespace: flux-system +spec: + image: kind-registry:5000/stefanprodan/podinfo + interval: 1m0s + insecure: true +``` + +### Alternatives +Instead of adding a flag, we can instruct users to make use of Kyverno policies to enforce that +all objects have `.spec.insecure` as `false` and any URLs present in the definition don't have `http` +as the scheme. This is less attractive, as this would ask users to install another software and prevent +Flux multi-tenancy from being standalone. From 6c7ef96354880408d263f610ff82dcac4f22a4ec Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Thu, 8 Sep 2022 09:55:49 +0530 Subject: [PATCH 3/9] add design details for insecure HTTP RFC Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 34 +++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 5f463ab4..55188260 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -136,3 +136,37 @@ Instead of adding a flag, we can instruct users to make use of Kyverno policies all objects have `.spec.insecure` as `false` and any URLs present in the definition don't have `http` as the scheme. This is less attractive, as this would ask users to install another software and prevent Flux multi-tenancy from being standalone. + +## Design Details +If a controller is started with `--insecure-allow-http=false`, any URL in a Flux object which has `http` +as the scheme will result in an error and the following condition will be added to the object's +`.status.conditions`: + +```yaml +status: + conditions: + - lastTransitionTime: "2022-09-06T09:14:21Z" + message: "Use of insecure HTTP connections isn't allowed for this controller" + observedGeneration: 1 + reason: URLInvalid + status: "True" + type: FetchFailedCondition +``` + +Similarly, if an object has `.spec.insecure` as `true` but the Cloud provider doesn't allow HTTP connections, +the reconciler will error out and add the condition below to the object's `.status.conditions`: + +```yaml +status: + conditions: + - lastTransitionTime: "2022-09-06T09:14:21Z" + message: "Use of insecure HTTP connections isn't allowed for Azure Storage" + observedGeneration: 1 + reason: InsecureConnectionsDisallowed + status: "True" + type: FetchFailedCondition +``` + +If an object has `.spec.insecure` as `true`, the registry client or bucket client shall be created with the use +of HTTP connections enabled explicitly. + From 7a1d978339760115dad1c3b478f09eade871781d Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Thu, 8 Sep 2022 12:38:32 +0530 Subject: [PATCH 4/9] add details about CLI in insecure HTTP RFC Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 55188260..6a838f1a 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -83,6 +83,20 @@ that the registry is hosted at a non-TLS endpoint. For such objects, we shall introduce a new boolean field `.spec.insecure`, which shall be `false` by default. Users that need their object to point to an HTTP endpoint, can set this to `true`. +### CLI +The Flux CLI offers several commands for creating Flux specific resources. Some of these commands may involve specifying +an endpoint such as creating an `OCIRepository`: + +```sh + flux create source oci podinfo \ + --url=oci://ghcr.io/stefanprodan/manifests/podinfo \ + --tag=6.1.6 \ + --interval=10m +``` + +Since these commands essentially create object definitions, the CLI should offer a boolean flag `--insecure` +for relevant objects, which will be used for specifying the value of `.spec.insecure` of such objects. + ### Precedence & Validity Objects with `.spec.insecure` as `true ` will only be allowed if HTTP connections are allowed at the controller level. Similarly, an object can have `.spec.insecure` as `true` only if the Saas/Cloud provider allows HTTP connections. @@ -137,9 +151,9 @@ all objects have `.spec.insecure` as `false` and any URLs present in the definit as the scheme. This is less attractive, as this would ask users to install another software and prevent Flux multi-tenancy from being standalone. -## Design Details +## Design Details If a controller is started with `--insecure-allow-http=false`, any URL in a Flux object which has `http` -as the scheme will result in an error and the following condition will be added to the object's +as the scheme will result in an error and the following condition will be added to the object's `.status.conditions`: ```yaml From 7a5f60e23f62380d49d1123168435129a236785c Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Mon, 12 Sep 2022 13:42:53 +0530 Subject: [PATCH 5/9] address concerns about kustomize and helm controller Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 6a838f1a..15f328da 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -20,7 +20,7 @@ Controllers that deal only with `http` and `https` schemes have no way to block Some Flux objects provide a `.spec.insecure` field to enable the use of non-TLS based endpoints, but they don't clearly notify users when the option is not supported (e.g. Azure/GCP Buckets). ### Goals -* Provide a flag across all Flux controllers which disables all outgoing HTTP connections. +* Provide a flag across relevant Flux controllers which disables all outgoing HTTP connections. * Add a field which enables the use of non-TLS endpoints to appropriate Flux objects. * Provide a way for users to be made aware that their use of non-TLS endpoints is not supported if that is the case. @@ -95,7 +95,10 @@ an endpoint such as creating an `OCIRepository`: ``` Since these commands essentially create object definitions, the CLI should offer a boolean flag `--insecure` -for relevant objects, which will be used for specifying the value of `.spec.insecure` of such objects. +for the required commands, which will be used for specifying the value of `.spec.insecure` of such objects. + +> Note: This flag should not be confused with `--insecure-skip-tls-verify` which is meant to skip TLS verification +> when using an HTTPS connection. ### Precedence & Validity Objects with `.spec.insecure` as `true ` will only be allowed if HTTP connections are allowed at the controller level. @@ -103,7 +106,6 @@ Similarly, an object can have `.spec.insecure` as `true` only if the Saas/Cloud For example, using a `Bucket` with its `.spec.provider` set to `azure` would be invalid since Azure doesn't allow HTTP connections. - ### User Stories #### Story 1 @@ -125,7 +127,17 @@ patches: value: --allow-insecure-http=false target: kind: Deployment - name: "(kustomize-controller|helm-controller|source-controller|notification-controller)" + name: "(source-controller|notification-controller|image-reflector-controller|image-automation-controller)" + # Since this above flag is not available in kustomize-controller for reasons explained in a previous section, + # we disable the Kustomize remote build by disallowing use of remote bases. This ensures that kustomize-controller + # won't initiate any plain HTTP connections. + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --no-remote-bases=true + target: + kind: Deployment + name: kustomize-controller ``` #### Story 2 From 443212d3daa8cef54a0787a89d4bf8ae72c3973a Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Thu, 29 Sep 2022 17:43:51 +0530 Subject: [PATCH 6/9] rename flag and propose renaming insecure-kubeconfig-tls Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 32 ++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 15f328da..c20a1705 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -17,7 +17,8 @@ logs and status conditions. Today the use of non-TLS based connections is inconsistent across Flux controllers. Controllers that deal only with `http` and `https` schemes have no way to block use of the `http` scheme at controller-level. -Some Flux objects provide a `.spec.insecure` field to enable the use of non-TLS based endpoints, but they don't clearly notify users when the option is not supported (e.g. Azure/GCP Buckets). +Some Flux objects provide a `.spec.insecure` field to enable the use of non-TLS based endpoints, but they don't clearly notify +users when the option is not supported (e.g. Azure/GCP Buckets). ### Goals * Provide a flag across relevant Flux controllers which disables all outgoing HTTP connections. @@ -26,26 +27,18 @@ Some Flux objects provide a `.spec.insecure` field to enable the use of non-TLS ### Non-Goals * Break Flux's current behavior of allowing HTTP connections. +* Change in behavior of communication between Flux components. ## Proposal ### Controllers Flux users should be able to enforce that controllers are using HTTPS connections only. -This shall be enabled by adding a new boolean flag `--allow-insecure-http` to the following controllers: +This shall be enabled by adding a new boolean flag `--insecure-allow-http` to the following controllers: * source-controller * notification-controller * image-automation-controller * image-reflector-controller -> Note: The flag shall not be added to the following controllers: -> * kustomize-controller: This flag is excluded from this controller, as the upstream `kubenetes-sigs/kustomize` project -> does not support disabling HTTP connections while fetching resources from remote bases. We can revisit this if the -> upstream project adds support for this at a later point in time. -> * helm-controller: This flag does not serve a purpose in this controller, as the controller does not make any HTTP calls. -> Furthermore although both controllers can also do remote applies, serving `kube-apiserver` over plain -> HTTP is disabled by default. While technically this can be enabled, the option for this configuration was also disabled -> quite a while back (ref: https://github.com/kubernetes/kubernetes/pull/65830/). - The default value of this flag shall be `true`. This would ensure that there is no breaking change with controllers still being able to access non-TLS endpoints. To disable this behavior and enforce the use of HTTPS connections, users would have to explicitly pass the flag to the controller: @@ -64,9 +57,22 @@ spec: - --enable-leader-election - --storage-path=/data - --storage-adv-addr=source-controller.$(RUNTIME_NAMESPACE).svc.cluster.local. - - --allow-insecure-http=false + - --insecure-allow-http=false ``` +> Note: The flag shall not be added to the following controllers: +> * kustomize-controller: This flag is excluded from this controller, as the upstream `kubenetes-sigs/kustomize` project +> does not support disabling HTTP connections while fetching resources from remote bases. We can revisit this if the +> upstream project adds support for this at a later point in time. +> * helm-controller: This flag does not serve a purpose in this controller, as the controller does not make any HTTP calls. +> Furthermore although both controllers can also do remote applies, serving `kube-apiserver` over plain +> HTTP is disabled by default. While technically this can be enabled, the option for this configuration was also disabled +> quite a while back (ref: https://github.com/kubernetes/kubernetes/pull/65830/). + +Both kustomize-controller and helm-controller currently have a flag `--insecure-kubeconfig-tls` which makes the controller skip +TLS verification when connecting to a Kubernetes cluster with an HTTPS connection. This flag shall be renamed to +`--insecure-skip-tls-verify` to align it with the Flux CLI which offers this command for the same purpose. + ### Objects Some Flux objects, like `GitRepository`, provide a field for specifying a URL, and the URL would contain the scheme. In such cases, the scheme can be used for inferring the transport type of the connection and consequently, @@ -124,7 +130,7 @@ patches: - patch: | - op: add path: /spec/template/spec/containers/0/args/- - value: --allow-insecure-http=false + value: --insecure-allow-http=false target: kind: Deployment name: "(source-controller|notification-controller|image-reflector-controller|image-automation-controller)" From a17210f3878512f4579b4c51362f5457685f145b Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Wed, 12 Oct 2022 15:20:55 +0530 Subject: [PATCH 7/9] add implementation history section Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index c20a1705..533db0ae 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -202,3 +202,8 @@ status: If an object has `.spec.insecure` as `true`, the registry client or bucket client shall be created with the use of HTTP connections enabled explicitly. +## Implementation History + +**2022-08-12** Allow defining OCI sources for non-TLS container registries with `flux create source oci --insecure` +released with [flux2 v0.34.0](https://github.com/fluxcd/flux2/releases/tag/v0.34.0) + From f3da59e5af12264e6bf3653dc3b4bf406844512a Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Fri, 14 Oct 2022 11:00:05 +0530 Subject: [PATCH 8/9] fix markdown formatting and update status conditions Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 56 ++++++++++++++++++------------- 1 file changed, 32 insertions(+), 24 deletions(-) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 533db0ae..9e073916 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -5,15 +5,17 @@ **Creation Date:** 2022-09-08 ## Summary + Flux should have a consistent way of disabling insecure HTTP connections. At the controller level, a flag should be present which would disable all outgoing HTTP connections. At the object level, a field should be provided which would enable the use of non-TLS endpoints. -If the use of a non-TLS endpoint is not supported, it should be made clear to users through the use of -logs and status conditions. +If the use of a non-TLS endpoint is not supported, reconciliation will fail and the object will be marked +as stalled, signalling that human intervention is required. ## Motivation + Today the use of non-TLS based connections is inconsistent across Flux controllers. Controllers that deal only with `http` and `https` schemes have no way to block use of the `http` scheme at controller-level. @@ -21,17 +23,20 @@ Some Flux objects provide a `.spec.insecure` field to enable the use of non-TLS users when the option is not supported (e.g. Azure/GCP Buckets). ### Goals + * Provide a flag across relevant Flux controllers which disables all outgoing HTTP connections. * Add a field which enables the use of non-TLS endpoints to appropriate Flux objects. * Provide a way for users to be made aware that their use of non-TLS endpoints is not supported if that is the case. ### Non-Goals + * Break Flux's current behavior of allowing HTTP connections. * Change in behavior of communication between Flux components. ## Proposal ### Controllers + Flux users should be able to enforce that controllers are using HTTPS connections only. This shall be enabled by adding a new boolean flag `--insecure-allow-http` to the following controllers: * source-controller @@ -60,27 +65,24 @@ spec: - --insecure-allow-http=false ``` -> Note: The flag shall not be added to the following controllers: -> * kustomize-controller: This flag is excluded from this controller, as the upstream `kubenetes-sigs/kustomize` project -> does not support disabling HTTP connections while fetching resources from remote bases. We can revisit this if the -> upstream project adds support for this at a later point in time. -> * helm-controller: This flag does not serve a purpose in this controller, as the controller does not make any HTTP calls. -> Furthermore although both controllers can also do remote applies, serving `kube-apiserver` over plain -> HTTP is disabled by default. While technically this can be enabled, the option for this configuration was also disabled -> quite a while back (ref: https://github.com/kubernetes/kubernetes/pull/65830/). - -Both kustomize-controller and helm-controller currently have a flag `--insecure-kubeconfig-tls` which makes the controller skip -TLS verification when connecting to a Kubernetes cluster with an HTTPS connection. This flag shall be renamed to -`--insecure-skip-tls-verify` to align it with the Flux CLI which offers this command for the same purpose. +**Note:** The flag shall not be added to the following controllers: +* kustomize-controller: This flag is excluded from this controller, as the upstream `kubenetes-sigs/kustomize` project +does not support disabling HTTP connections while fetching resources from remote bases. We can revisit this if the +upstream project adds support for this at a later point in time. +* helm-controller: This flag does not serve a purpose in this controller, as the controller does not make any HTTP calls. +Furthermore although both controllers can also do remote applies, serving `kube-apiserver` over plain +HTTP is disabled by default. While technically this can be enabled, the option for this configuration was also disabled +quite a while back (ref: https://github.com/kubernetes/kubernetes/pull/65830/). ### Objects + Some Flux objects, like `GitRepository`, provide a field for specifying a URL, and the URL would contain the scheme. In such cases, the scheme can be used for inferring the transport type of the connection and consequently, whether to use HTTP or HTTPS connections for that object. But there are a few objects that don't allow such behavior, for example: -* `ImageRepository`: It provides a field, `.spec.image`, which is used for specifying the URL of the image present on -a container registry. But any URL containing a scheme is considered invalid and HTTPS is the default transport used. +* `ImageRepository`: It provides a field, `.spec.image`, which is used for specifying the address of the image present on +a container registry. But any address containing a scheme is considered invalid and HTTPS is the default transport used. This prevents users from using images present on insecure registries. * OCI `HelmRepository`: When using an OCI registry as a Helm repository, the `.spec.url` is expected to begin with `oci://`. Since the scheme part of the URL is used to specify the type of `HelmRepository`, there is no way for users to specify @@ -90,6 +92,7 @@ For such objects, we shall introduce a new boolean field `.spec.insecure`, which need their object to point to an HTTP endpoint, can set this to `true`. ### CLI + The Flux CLI offers several commands for creating Flux specific resources. Some of these commands may involve specifying an endpoint such as creating an `OCIRepository`: @@ -107,6 +110,7 @@ for the required commands, which will be used for specifying the value of `.spec > when using an HTTPS connection. ### Precedence & Validity + Objects with `.spec.insecure` as `true ` will only be allowed if HTTP connections are allowed at the controller level. Similarly, an object can have `.spec.insecure` as `true` only if the Saas/Cloud provider allows HTTP connections. For example, using a `Bucket` with its `.spec.provider` set to `azure` would be invalid since Azure doesn't allow @@ -115,6 +119,7 @@ HTTP connections. ### User Stories #### Story 1 + > As a cluster admin of a multi-tenant cluster, I want to ensure all controllers access endpoints using only HTTPS > regardless of tenants' object definitions. @@ -134,8 +139,8 @@ patches: target: kind: Deployment name: "(source-controller|notification-controller|image-reflector-controller|image-automation-controller)" - # Since this above flag is not available in kustomize-controller for reasons explained in a previous section, - # we disable the Kustomize remote build by disallowing use of remote bases. This ensures that kustomize-controller + # Since the above flag is not available in kustomize-controller for reasons explained in a previous section, + # we disable Kustomize remote builds by disallowing use of remote bases. This ensures that kustomize-controller # won't initiate any plain HTTP connections. - patch: | - op: add @@ -147,6 +152,7 @@ patches: ``` #### Story 2 + > As an application developer, I'm trying to debug a new image pushed to my local registry which > is not served over HTTPS. @@ -164,14 +170,16 @@ spec: ``` ### Alternatives + Instead of adding a flag, we can instruct users to make use of Kyverno policies to enforce that all objects have `.spec.insecure` as `false` and any URLs present in the definition don't have `http` as the scheme. This is less attractive, as this would ask users to install another software and prevent Flux multi-tenancy from being standalone. ## Design Details + If a controller is started with `--insecure-allow-http=false`, any URL in a Flux object which has `http` -as the scheme will result in an error and the following condition will be added to the object's +as the scheme will result in an unsuccessful reconciliation and the following condition will be added to the object's `.status.conditions`: ```yaml @@ -180,13 +188,13 @@ status: - lastTransitionTime: "2022-09-06T09:14:21Z" message: "Use of insecure HTTP connections isn't allowed for this controller" observedGeneration: 1 - reason: URLInvalid + reason: InsecureConnectionsDisallowed status: "True" - type: FetchFailedCondition + type: Stalled ``` Similarly, if an object has `.spec.insecure` as `true` but the Cloud provider doesn't allow HTTP connections, -the reconciler will error out and add the condition below to the object's `.status.conditions`: +the reconciliation will fail and the following condition will be added to the object's `.status.conditions`: ```yaml status: @@ -194,9 +202,9 @@ status: - lastTransitionTime: "2022-09-06T09:14:21Z" message: "Use of insecure HTTP connections isn't allowed for Azure Storage" observedGeneration: 1 - reason: InsecureConnectionsDisallowed + reason: UnsupportedConnectionType status: "True" - type: FetchFailedCondition + type: Stalled ``` If an object has `.spec.insecure` as `true`, the registry client or bucket client shall be created with the use From 98c7afd69c3cea97a7aecec2ed588729e2d608ec Mon Sep 17 00:00:00 2001 From: Sanskar Jaiswal Date: Tue, 18 Oct 2022 14:32:32 +0530 Subject: [PATCH 9/9] add last updated date and mark as implementable Signed-off-by: Sanskar Jaiswal --- rfcs/0004-insecure-http/README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rfcs/0004-insecure-http/README.md b/rfcs/0004-insecure-http/README.md index 9e073916..bcf9782a 100644 --- a/rfcs/0004-insecure-http/README.md +++ b/rfcs/0004-insecure-http/README.md @@ -1,9 +1,11 @@ # RFC-0004 Block insecure HTTP connections across Flux -**Status:** provisional +**Status:** implementable **Creation Date:** 2022-09-08 +**Last update:** 2022-10-21 + ## Summary Flux should have a consistent way of disabling insecure HTTP connections.