Add hostRef to ClusterAccess Spec

[vertex451]

Problem/Motivation

Currently, the host field within the ClusterAccess custom resource (spec.host) requires the host URL to be directly specified in the manifest. While functional, this approach can be inflexible, especially when dealing with environment-specific URLs, sensitive hostnames that should not be directly committed to Git, or when aiming for better secrets management practices.

To enhance flexibility and security, it would be beneficial to allow the host value to be dynamically sourced from a Kubernetes ConfigMap or Secret. This would align with how other sensitive or configurable parameters, such as ca and auth details, are handled via references in the ClusterAccess resource.

Proposed Solution

Introduce a new optional field, hostRef, within the ClusterAccess spec. This field would allow referencing a ConfigMap or Secret containing the cluster host URL.

The proposed structure for hostRef would be similar to existing reference patterns in Kubernetes, for example:

apiVersion: gateway.openmfp.org/v1alpha1
kind: ClusterAccess
metadata:
  name: my-cluster-access
spec:
  # Existing host field (mutually exclusive with hostRef)
  # host: https://my-cluster.com

  # Proposed new field
  hostRef:
    configMapRef:
      name: my-host-configmap
      namespace: default
      key: cluster-host-url
    # OR
    secretRef:
      name: my-host-secret
      namespace: default
      key: cluster-host-url

Considerations:

• Mutual Exclusivity: The host and hostRef fields should be mutually exclusive. If both are specified, a clear validation error should be provided (e.g., hostRef takes precedence, or an error is thrown).
• Validation: Ensure robust validation for the hostRef structure, including checks for required name, namespace, and key fields. The content retrieved from the referenced ConfigMap or Secret should also be validated as a valid URL.

[tobias-oetzel]

Since the kubeconfig also contains the hoist, can the host be made optional, when a kubeconfig secret is used?

[aaronschweig]

Since the kubeconfig also contains the hoist, can the host be made optional, when a kubeconfig secret is used?

I would vote for that - makes a lot of sense