This change replaces the usage of Service Tokens by OIDC tokens in the instructions of Kubernetes cluster local and remote access. Some other changes were made, like the deletion of redundant pages. Story: 2010738 Task: 49561 Change-Id: Ie8206ecd316efd356a5889899a68f9a9ddbcdfa6 Signed-off-by: Joao Victor Portal <Joao.VictorPortal@windriver.com>
4.2 KiB
Centralized vs Distributed OIDC Authentication Setup
In a configuration, you can configure authentication in a distributed or centralized setup. For other configurations, like , or Standard Cloud, follow the instructions in the distributed setup documented below.
Distributed Setup
For a distributed setup, configure the kube-apiserver and the oidc-auth-apps independently for each cloud, System Controller, and all subclouds. The oidc-auth-apps runs on each active controller of the setup and the kube-apiserver is configured to point to the local instance of oidc-auth-apps. 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 authentication servers (Windows Active Directory and/or ). 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 either 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.
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>
Configure the oidc-auth-apps only on the System Controller. 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 Kubernetes Client Access <configure-kubernetes-client-access>