starlingx/docs
Code Issues Proposed changes
93e265fbf3
docs/doc/source/security/kubernetes/centralized-oidc-authentication-setup-for-distributed-cloud.rst
Ron Stone f125a8b892 Remove spurious escapes (r8,dsR8) 
This change addresses a long-standing issue in rST documentation imported from XML.
That import process added backslash escapes in front of various characters. The three
most common being '(', ')', and '_'.
These instances are removed.

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: Id43a9337ffcd505ccbdf072d7b29afdb5d2c997e
2023-03-01 11:19:04 +00:00

4.5 KiB
Raw Blame History

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:

  1. 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>

  2. 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>