Use secret types to select the authentication scheme

The current version of this ADR proposes to use one secret type
per protocol, which is somewhat limiting. It would be reasonable to
consider the use of a basic auth secret for authentication to an OCI
registry, for instance. Also, the use of the secret type to select the
authentication scheme would help to reduce any potential ambiguity.

In the case of OCI registries, the ADR already explicitly mentions the
dockerconfigjson secret type. For HTTP[S], it falls back on the Opaque
type and attempts to figure out the appropriate authentication method
based on the contents of the secret. This is inconsistent with the way
it works for OCI, and can be made consistent by adding a custom secret
type for the case that k0s wants to cover, but for which there's no
predefined type available upstream.

Signed-off-by: Tom Wieczorek <[email protected]>

docs/architecture/adr-001-autopilot-oci-basic-auth-support.md

@@ -66,10 +66,7 @@ type PlanResourceURL struct {
 
 `SecretRef` property is of type `SecretReference` as defined by
 `k8s.io/api/core/v1` package. The secret pointed by the provided `SecretRef`
-will be used for pulling artifacts using either HTTP[S] or OCI protocols and is
-expected to by of type `kubernetes.io/dockerconfigjson` if the protocol in use
-is `oci://` or of type `Opaque` if protocols `http://` or `https://` are used
-(see below for details on the Secret layout).
+will be used for pulling artifacts using either HTTP[S] or OCI protocols.
 
 Example configuration for OCI:
 
@@ -103,48 +100,47 @@ secretRef:
 
 ### Secrets Layout
 
-For secrets of type `kubernetes.io/dockerconfigjson` the format is the default
-for Docker authentications, equal to what is used in a Pod's pull secret. For
-further details you can refer to the [official
-documentation](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
+The following standard Kubernetes secret types are supported:
 
-When it comes to the `Opaque` secret layout (used for HTTP requests) Autopilot
-will accept the following entries:
+- [`kubernetes.io/basic-auth`](https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret)<br>
 
-- `username` and `password`: if both are set then Autopilot will attempt to
-  pull the artifacts using [Basic
-  Authentication](https://www.ibm.com/docs/en/cics-ts/6.1?topic=concepts-http-basic-authentication).
-- `authorization`: if this property is set then the `Authorization`
-  [header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)
-  will be set to its value when pulling the artifacts.
+- [`kubernetes.io/dockerconfigjson`](https://kubernetes.io/docs/concepts/configuration/secret/#docker-config-secrets)<br>
+   It works in the same way as a Pod's [image pull secret]. Only supported for
+  the `oci://` protocol. (Might be supported for other protocols in the future,
+  as well).
 
-No other property will be parsed and used. For sake of defining the expected
-behaviour in case of conflicting configurations:
+[image pull secret]: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
 
-> In the case where the three properties are set (`username`, `password`, and
-> `authorization`) Autopilot will ignore `username` and `password`, i.e.
-> `authorization`  takes precedence over username and password.
+Potentially supported in the future:
 
-The `authorization` entry is used as is, its content is placed directly into
-the `Authorization` header. For example a secret like the following will make
-Autopilot to set the `Authorization` header to `Bearer abc123def456ghi789jkl0`:
+- [`kubernetes.io/tls`](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)<br>
+  For TLS client authentication.
 
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: creds
-  namespace: kube-system
-data:
-  authorization: "Bearer abc123def456ghi789jkl0"
-```
+Moreover, k0s supports the following custom secret type:
+
+- `k0sproject.io/http-authorization-header`<br>
+  Sets a custom value for the HTTP Authorization header:
+
+  ```yaml
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: creds
+    namespace: kube-system
+  data:
+    authorization: "Bearer abc123def456ghi789jkl0"
+  ```
+
+  The `authorization` entry is used as is, with its content placed directly into
+  the `Authorization` header. For example, a secret like the following will make
+  Autopilot set the `Authorization` header to `Bearer abc123def456ghi789jkl0`.
 
 ### Additional Details
 
-- The `InsecureSkipTLSVerify` property is equivalent of defining
+- The `InsecureSkipTLSVerify` property is equivalent to defining
   `InsecureSkipTLSVerify` on a Go HTTP client.
 - The `InsecureSkipTLSVerify` property will be valid for both `oci://` and
-  `https://` protocols.
+  `https://` protocols. It has no effect for the `http://` protocol.
 - If a protocol is not specified or an incorrect one is provided, an error
   state should be activated.
 - If no `SecretRef` is defined, access will be anonymous (no authentication).