-
Notifications
You must be signed in to change notification settings - Fork 431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🏃add draft of multi-tenancy proposal #809
Conversation
the principal types. Upon receiving an update event, the controller will update lookup the key in | ||
the cache and update the relevant `Authorizer`. This may be implemented as its own interface. | ||
Mutexes will ensure in-flight updates are completed prior to SDK calls are made. This would require | ||
changes to RBAC, and maintaining a watch on secrets of a specific type will require further |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maintaining a watch on secrets of a specific type will require further
investigation as to feasibility
this sounds fine to me, anything you're worried about? if there's any identifying metadata you can use it to write a filter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not, but the CAPA authors were. Not sure if I missed something... Wanted to leave it in for someone smarter than me to spot the hole.
* The controller will set the Identity resource as one of the OwnerReferences of the AzureCluster. | ||
|
||
### Clusterctl changes | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
related issue in cluster-api kubernetes-sigs/cluster-api#3354
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the proposal is sane, I like the proposed API changes. Mostly added some clarifying questions/comments.
<a name="FR3">FR3.</a> CAPZ MUST prevent privilege escalation allowing users to create clusters in Azure accounts they should | ||
not be able to. | ||
|
||
<a name="FR4">FR4.</a> CAPZ SHOULD support credential refreshing modified principal data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is an example of this being able to refresh an expired service principal secret to be able to keep managing an existing cluster?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more about someone changing the content of the secret, which should cause the Authorizer
cache to revoke the existing Authorizer
and rebuild it from the changed secret.
|
||
<a name="FR4">FR4.</a> CAPZ SHOULD support credential refreshing modified principal data. | ||
|
||
<a name="FR5">FR5.</a> CAPZ SHOULD provide validation for principal data submitted by users. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what kind of validation? Does that include validating that the credentials are valid/not expired?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to attempt to get a token from AAD. If we are unable to get a token from AAD, perhaps we get a 401, we should reject the secret as invalid.
|
||
### Non-Functional | ||
|
||
<a name="NFR1">NFR1.</a> Each instance of CAPZ SHOULD be able to support 200 clusters using role assumption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why 200?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a reasonable aspiration and was part of the CAPA proposal.
|
||
<em>Cluster scoped resources</em> | ||
|
||
* `AzureServicePrincipal` represents an AAD Service Principal. Should support both |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
related to #778
imperfect. For example, a change to an Azure Identity resource could affect the validity of | ||
corresponding AzureCluster. | ||
|
||
#### Principal Type Credential Provider Behaviour |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conversion changes? What happens if you have a v1alpha3 cluster using SystemAssigned identity and you try to convert to v1alpha2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great question. I think that fails.
We could add the identity information to the metadata of the v1alpha2 version of the AzureCluster. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should at least document that as breaking. Wonder how CAPA is handling conversion... we should probably align on that.
eae3e0a
to
ed06a34
Compare
I think I've addressed all of the feedback thus far. PTAL when you all have a min. |
Name string `json:"name"` | ||
} | ||
|
||
type AzureClusterSpec struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just thought about this, what's the impact on the subscriptionID field in AzureClusterSpec? None right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes should have no impact on subscriptionID.
An AAD identity has nothing to do with a subscription. Auth only needs the tenant, client ID, a secret, and resource or scopes.
If one day in the future we decide to build multi-subscription clusters, then we'd have to make a change to subscription ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Thanks for the clarification.
/hold Starting lazy consensus for a week from now (7/31) |
another quick question: I assume this has no impact on #481, correct? Since this is for identity for infra provisioning |
@CecileRobertMichon, nope. I think this is more for user auth to the cluster (kubectl auth). |
Last chance for comments, will remove the hold Monday morning |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
lgtm |
/hold cancel |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: CecileRobertMichon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
What this PR does / why we need it:
We need to provide the Cluster an identity to use for provisioning besides the default identity of the controller. This will enable the CAPZ controllers to work as a single instance with multiple tenants.
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 #586
see also: kubernetes-sigs/cluster-api-provider-aws#1674
Big thank you to @randomvariable and @andrewmyhre! I cribbed much of this document from the AWS provider proposal.
TODOs:
Release note: