address concerns about kustomize and helm controller

Signed-off-by: Sanskar Jaiswal <[email protected]>

rfcs/0004-insecure-http/README.md

@@ -16,11 +16,11 @@ logs and status conditions.
 ## Motivation
 Today the use of non-TLS based connections is inconsistent across Flux controllers.
 
-Controllers that deals only with `http` and `https` schemes have no way to block use of the `http` scheme at controller-level.
+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 an `.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.
 
@@ -30,9 +30,23 @@ Some Flux objects provide an `.spec.insecure` field to enable the use of non-TLS
 ## Proposal
 
 ### Controllers
-Flux users, especially cluster admins should be able to enforce that all controllers are using only HTTPS connections
-This shall be enabled by adding a new flag to all controllers `--allow-insecure-http`.
-The default value of this flag shall be `false`. This would ensure that there is no breaking change with 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 also have the ability to 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 `false`. 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:
 
@@ -81,12 +95,15 @@ 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 & Validitiy
-Objects with `.spec.insecure` as `true `will only be allowed if HTTP connections are allowed at the controller
+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.
+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.
 
@@ -112,7 +129,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