-
Notifications
You must be signed in to change notification settings - Fork 710
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
Initial documentation for Multi-cluster support. #1951
Initial documentation for Multi-cluster support. #1951
Conversation
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.
IMO, this guide exposes generic problems but I was expecting a step by step guide to have this working, even if it's just for a kind + dex demo environment. Speaking for myself, it wouldn't be trivial for me to setup this environment following this.
I am approving to not block the release, I believe the guide I mention is not needed for people to start trying this. Thanks!
|
||
To use this feature, you need to have your Kubernetes API servers for each cluster configured to trust the same OpenID Connect provider, whether that be a specific commercial OAuth2 provider such as Google, Azure or Github, or an instance of [Dex](/~https://github.com/dexidp/dex). | ||
|
||
Once you have selected and configured your OIDC provider, refer to the [Kubernetes docs to configure your API servers to trust the OIDC provider](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server). |
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's probably helpful to show how to do this with Dex.
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've added an example configuring Dex with a single static client here, and linked to our existing docs on Kubeapps with an OIDC setup. Also, there are links to the local dev examples below as well (two paragraphs below).
|
||
## Clusters with different client-ids | ||
|
||
Some multi-cluster environments configure each cluster's API server with its own client-id for the chosen OAuth2 provider. In this case, there is some extra configuration required to ensure the OIDC token used by Kubeapps is accepted by the different clusters. |
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 would add examples or how to know if you need this configuration.
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 next two sub-sections have examples of doing this with dex. I've updated the above sentence to show an example from the TKG documentation where you are asked to do this, and ensured that it's obvious that the following sub-sections flow from here.
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.
but I was expecting a step by step guide to have this working, even if it's just for a kind + dex demo environment. Speaking for myself, it wouldn't be trivial for me to setup this environment following this.
Yes - it's not trivial to setup multiple K8s clusters with oidc support. Read the TKG instructions and you'll see it involves many pages of specific instructions to edit certain files with certain values etc. Luckily we've automated it for a local dev environment.
It also wasn't trivial for me to find a solution to the multiple client-ids used by TKG (spent a good part of a week looking for the best solution which turns out to be relatively trivial - trusted peers and requesting extra audiences via the scope).
Regarding a step-by-step setup for kind + dex, I wanted to mention that it's automated (ie. if you have kind and mkcerts installed, you can just make multi-cluster-kind
to get the two clusters setup ready to trust dex, and then after exporting your KUBECONFIG, make deploy-dev
to install dex, openldap and kubeapps all working together in a multi-cluster env, but I haven't included this in the doc. Perhaps we should?
I am approving to not block the release, I believe the guide I mention is not needed for people to start trying this. Thanks!
Great, thanks.
|
||
To use this feature, you need to have your Kubernetes API servers for each cluster configured to trust the same OpenID Connect provider, whether that be a specific commercial OAuth2 provider such as Google, Azure or Github, or an instance of [Dex](/~https://github.com/dexidp/dex). | ||
|
||
Once you have selected and configured your OIDC provider, refer to the [Kubernetes docs to configure your API servers to trust the OIDC provider](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server). |
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've added an example configuring Dex with a single static client here, and linked to our existing docs on Kubeapps with an OIDC setup. Also, there are links to the local dev examples below as well (two paragraphs below).
|
||
## Clusters with different client-ids | ||
|
||
Some multi-cluster environments configure each cluster's API server with its own client-id for the chosen OAuth2 provider. In this case, there is some extra configuration required to ensure the OIDC token used by Kubeapps is accepted by the different clusters. |
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 next two sub-sections have examples of doing this with dex. I've updated the above sentence to show an example from the TKG documentation where you are asked to do this, and ensured that it's obvious that the following sub-sections flow from here.
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.
Regarding a step-by-step setup for kind + dex, I wanted to mention that it's automated (ie. if you have kind and mkcerts installed, you can just
make multi-cluster-kind
to get the two clusters setup ready to trust dex, and then after exporting your KUBECONFIG,make deploy-dev
to install dex, openldap and kubeapps all working together in a multi-cluster env, but I haven't included this in the doc. Perhaps we should?
Yes please, at the very minimum, it will be helpful for me to set this up quickly in my dev environment.
|
||
## Updating multicluster options | ||
|
||
TBD |
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.
BTW, this TBD
seems like the documentation is not finished (while I believe there is an open issue to support this), maybe we should elaborate this a bit more?
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 was intended to be understood that the documentation wasn't finished - I've filled this in with #1955 . Not sure which open issue you're thinking of?
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.
ah, I thought this was related to #1942
Also done in #1955 . |
* Initial documentation for Multi-cluster support. * Small improvements and typo fixes. * Include example of TKG requesting separate client id. * Wording improvements
Description of the change
Provides initial documentation for the multi-cluster support.
View the rendered markdown
Applicable issues