feat: multi-tenancy

[cbzzz]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Adds multi-tenancy for CAPL-managed clusters. Clusters may now reference an optional Secret containing their Linode credentials (i.e. API token) to be used for the deployment of "things" associated with their cluster.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

• From the design, it appears LinodeVPC and LinodeCluster objects are loosely-coupled and managed somewhat independently by the controller. I thought it was best to use a separate CredentialsRef field in the Spec for LinodeVPCs rather than doing a bigger refactor and trying to couple the two types.

• The $LINODE_TOKEN environment variable is always propagated into a Secret that will be created for every workload cluster. While a credentials Secret may be referenced by multiple workload clusters (or not at all), I thought generating a per-cluster Secret was best in the current cluster templating workflow.

TODOs:

• squashed commits
• includes documentation
• adds unit tests
• adds or updates e2e tests

Testing:

1. Create two Linode tokens, one with full "Read/Write" permissions ($GOOD_TOKEN) and one with full "None" permissions ($BAD_TOKEN).

2. Deploy two workload clusters, one per token:

❯ LINODE_TOKEN=$GOOD_TOKEN clusterctl generate cluster ${CLUSTER_NAME}-good \
  --kubernetes-version v1.29.1 \
  --infrastructure linode:0.0.0 \
  | kubectl apply -f -

❯ LINODE_TOKEN=$BAD_TOKEN clusterctl generate cluster ${CLUSTER_NAME}-bad \
  --kubernetes-version v1.29.1 \
  --infrastructure linode:0.0.0 \
  | kubectl apply -f -

3. A new credentials Secret is created for every workload cluster:

❯ kubectl get secrets
NAME                             TYPE                                   DATA   AGE
cbang-capl-bad-credentials       Opaque                                 1      10m
cbang-capl-good-credentials      Opaque                                 1      10m

4. The workload cluster with the valid token will provision successfully while the one with the invalid token will fail:

❯ kubectl get clusters
NAMESPACE   NAME              CLUSTERCLASS   PHASE         AGE     VERSION
default     cbang-capl-good                  Provisioned   10m
default     cbang-capl-bad                   Failed        10m

❯ kubectl logs -n capl-system capl-controller-manager-67cdf96488-q682z
2024-03-04T14:00:00Z    DEBUG   events  [401] Your OAuth token is not authorized to use this endpoint.  {"type": "Warning", "object": {"kind":"LinodeCluster","namespace":"default","name":"cbang-capl-bad","uid":"9ec42cbe-3214-4bf7-b9be-5eadcdf6d2bd","apiVersion":"infrastructure.cluster.x-k8s.io/v1alpha1","resourceVersion":"38418"}, "reason": "CreateError"}

NOTE: These tokens will be different from the default one (capl-system/capl-manager-credentials) that is used by CAPL if the Cluster does not reference a credentials Secret.

[AshleyDumaine]

Can we add a docs update on multi-tenancy under the topics section? 🙏

wrong button

[cbzzz]

Can we add a docs update on multi-tenancy under the topics section? 🙏

Can do! That one in-line comment wasn't doing it for you? 🙈

[AshleyDumaine]

I would slightly change the wording to note that this is for Linode resources associated with individual workload clusters such as Linodes, VPCs, and NodeBalancers.

[cbzzz]

Better? Worse? 🤔 9942590

[AshleyDumaine]

I would just replace "things" in the original paragraph with Linode resources (i.e. Linodes, VPCs, and NodeBalancers)

[AshleyDumaine]

LGTM