Global Pass Upgrades Added content from emails attached to ticket and sharepoint Pacth 01: inputs from email by Greg Patch 03: Created new section for subcloud group updated table 1 shared system configurations Patch 04: corrected typos (Mary's comments) Patch 05: solved merged conflict patch 06: removed broken link Story: TBD Task: TBD Signed-off-by: Adil <mohamed.adilassakkali@windriver.com> Change-Id: I60b0a40a60a44d30429cd3a4dd8374c16345951a
4.5 KiB
Centralized OIDC Authentication Setup for Distributed Cloud
In a configuration, you can configure authentication in a distributed or centralized setup.
Distributed Setup
For a distributed setup, configure the kube-apiserver, and oidc-auth-apps independently for each cloud, System Controller, and all subclouds. For more information, see:
- Configure Kubernetes for Token Validation
Configure Kubernetes for OIDC Token Validation while Bootstrapping the System <configure-kubernetes-for-oidc-token-validation-while-bootstrapping-the-system>
or
Configure Kubernetes for OIDC Token Validation after Bootstrapping the System <configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system>
Configure OIDC Auth Applications <configure-oidc-auth-applications>
All clouds oidc-auth-apps can be configured to communicate to the same or different remote Windows Active Directory servers, however, each cloud manages tokens individually. A user must login, authenticate, and get an token for each cloud independently.
Centralized Setup
For a centralized setup, the oidc-auth-apps is configured 'only' on the System Controller. The kube-apiserver must be configured on all clouds, System Controller, and all subclouds, to point to the centralized oidc-auth-apps running on the System Controller. In the centralized setup, a user logs in, authenticates, and gets an token from the Central System Controller's identity provider, and uses the token with 'any' of the subclouds as well as the System Controller cloud.
For a centralized authentication setup, use the following procedure:
Configure the kube-apiserver parameters on the System Controller and each subcloud during bootstrapping, or by using the system service-parameter-add kubernetes kube_apiserver command after bootstrapping the system, using the System Controller's floating OAM IP address as the oidc_issuer_url for all clouds. address as the oidc_issuer_url for all clouds.
For example, oidc_issuer_url=https://<central-cloud-floating-ip>:<oidc-auth-apps-dex -service-NodePort>/dex on the subcloud.
For more information, see:
Configure Kubernetes for OIDC Token Validation while Bootstrapping the System <configure-kubernetes-for-oidc-token-validation-while-bootstrapping-the-system>
or
Configure Kubernetes for OIDC Token Validation after Bootstrapping the System <configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system>
On the System Controller only configure the oidc-auth-apps. For more information, see:
Configure OIDC Auth Applications <configure-oidc-auth-applications>
Note
For IPv6 deployments, ensure that the IPv6 OAM floating address is, https://\[<central-cloud-floating-ip>]:30556/dex (that is, in lower case, and wrapped in square brackets).
For more information on configuring Users, Groups, Authorization, and kubectl for the user and retrieving the token on subclouds, see:
Configure Users, Groups, and Authorization <configure-users-groups-and-authorization>
Configure Kubectl with a Context for the User <configure-kubectl-with-a-context-for-the-user>
For more information on Obtaining the Authentication Token, see:
Obtain the Authentication Token Using the oidc-auth Shell Script <obtain-the-authentication-token-using-the-oidc-auth-shell-script>
Obtain the Authentication Token Using the Browser <obtain-the-authentication-token-using-the-browser>