Initial pass at stories for token registration #69
Conversation
|
Thanks! |
| 1. OCM agents in the spoke cluster were offline (e.g. due to an outage) during which its service account token expired | ||
| 2. A network outage resulted in the spoke cluster loosing connectivity to the hub api server for an extended period of time | ||
| 3. A service account was intentionally deleted (e.g. the associated token was compromised) and replaced. | ||
|
|
There was a problem hiding this comment.
we should have another story about addons. I think in token base approach, addons also need to use token to talk to the hub.
|
alternatively, we could build a front-proxy for kube-apiserver, the front-proxy can use mtls with a customized signer. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dgorst The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| @@ -0,0 +1,157 @@ | |||
| ## Release Signoff Checklist | |||
There was a problem hiding this comment.
Please add https://github.com/open-cluster-management-io/api/blob/main/docs/clusterjoinprocess.md as a see-also. It may be worth it to move the doc into this repo.
That doc outlines the current process and a few key features of the flow are visible there:
- the subject has a group associated with the managedcluster and the name has an agent associated with the process on that managedcluster
- an agent on the managedcluster is able to get new agent credentials by using shared (non-agent) credentials to create a request and the hub admin can approve or reject.
- an agent on the managedcluster is able renew credentials to identify itself. This also allows for non-shared credential flows.
- different agents on the managed cluster are members of the same group and have different names, with the agent clearly identified
- the hub admin gets a choice about whether or not to allow a particular managecluster to get a valid credential
- the hub admin can control expiry/removal of a particular agent. In this case, by rotating the signing credential. (Different distros are better or worse at doing this.)
Any new flow that is developed should allow the same capabilities and should use the standard group and usernames to ease adoption. Capability 2 may be negotiable (not required), but it would be limiting because the hub would need to communicate unique credentials to each managed cluster.
There was a problem hiding this comment.
👍 Added to implementation details section
Hey @mikeshng @skeeey @qiujian16 - as per discussion on Slack, firing over a PR covering the admin developer experience of joining/accepting clusters using token registration - just to get the conversation started. Technical details/impl notes/testing etc still need to be added to the doc