Provide more prescriptive guidance on multi-tenancy

[sbueringer]

From the PR that we previously had for this topics:

As a follow up to the Cluster API meeting of 2021/04/21, this PR intends to give more prescriptive guidance around the multi-tenancy contract. In particular, this documents how cluster scoped resources should work at the present time, and also in a
future release of Cluster API that drops support for older Kubernetes versions.
#4514

There doesn't seem to be a proposal in core Cluster API and the book only has this short documentation: https://cluster-api.sigs.k8s.io/developer/architecture/controllers/multi-tenancy.html

Multi tenancy
Multi tenancy in Cluster API defines the capability of an infrastructure provider to manage different credentials, each one of them corresponding to an infrastructure tenant.

Contract
In order to support multi tenancy, the following rule applies:

• Infrastructure providers MUST be able to manage different sets of credentials (if any)
• Providers SHOULD deploy and run any kind of webhook (validation, admission, conversion) following Cluster API codebase best practices for the same release.
• Providers MUST create and publish a {type}-component.yaml accordingly.

#4514 was a lot more concrete than our current documentation. I'm not sure what the current state on multi-tenancy implementations across providers is and what the starting point for a new PR would be.

/kind documentation
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[sbueringer]

cc @randomvariable @fabriziopandini @CecileRobertMichon @richardcase
In case you want to add something. Just thought it's better to at least track this in an issue vs a closed PR.

[fabriziopandini]

/triage accepted
/help
It would be great to revive #4514, but at the same time, I would like provider's teams to take ownership of defining a common baseline that the users can rely on across different providers and make it a formal contract.
If it could help. let's bring up this topic in the weekly meeting ...

[k8s-ci-robot]

@fabriziopandini:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/triage accepted
/help
It would be great to revive #4514, but at the same time, I would like provider's teams to take ownership of defining a common baseline that the users can rely on across different providers and make it a formal contract.
If it could help. let's bring up this topic in the weekly meeting ...

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sbueringer]

/triage accepted /help It would be great to revive #4514, but at the same time, I would like provider's teams to take ownership of defining a common baseline that the users can rely on across different providers and make it a formal contract. If it could help. let's bring up this topic in the weekly meeting ...

I agree. I just had it on my list of things that we lost a bit track of. I definitely think this should be discussed by providers if they want to get to more conformity that we currently have documented.

Added it to the agenda for this week.

[sbueringer]

@randomvariable just fyi that's the issue for it :)

[fabriziopandini]

/priority backlog