diff --git a/docs/deployment/configuration/auth_setup.rst b/docs/deployment/configuration/auth_setup.rst index 77681d71ba..92eeb89d9d 100644 --- a/docs/deployment/configuration/auth_setup.rst +++ b/docs/deployment/configuration/auth_setup.rst @@ -17,13 +17,16 @@ The following diagram summarizes the components and their interactions as part o In summary, there are two main resources required for a complete auth flow in Flyte: -**An identity layer** +**Identity Layer** -Using an implementation of the `Open ID Connect (OIDC) specification `__, it enables clients to verify the identity of the end user based on the authentication performed by an Authorization Server. For this flow to work, you must first register Flyte as a new client (app) to the Identity Provider (IdP). +The `OpenID Connect (OIDC) protocol `__ allows clients (such as Flyte) to confirm the identity of a user, based on authentication done by an Authorization Server. To enable this, you first need to register Flyte as an app (client) with your chosen Identity Provider (IdP). **An authorization server** -As defined by IETF's `RFC #6749 `__, the authorization server's role is to issue *access tokens to the client after successfully authenticating the resource owner and obtaining authorization*. In this context, the *resource owner* is the end user of Flyte; and the *client* is the tool or component that intends to interact with ``flyteadmin`` : ``flytepropeller``, ``flyteconsole`` or any of the CLI tools. +As defined by IETF's `RFC #6749 `__ , the authorization server’s job is to issue access tokens to clients after verifying the user (resource owner) and getting their consent. In this setup: + + 1. The user of Flyte, is the *resource owner*. + 2. The *client* is the tool or component that intends to interact with ``flyteadmin`` : ``flytepropeller``, ``flyteconsole`` or any of the CLI tools like ``flytectl``. There are two supported options to use an authorization server in Flyte: @@ -122,29 +125,60 @@ browser. .. group-tab:: Microsoft Entra ID (Azure AD) - 1. From the Azure homepage go to **Azure Active Directory** - 2. From the **Ovierview** page, take note of the **Tenant ID** - 3. Go to **App registrations** - 4. Create a **New registration** - 5. Give it a descriptive name - 6. For the **Supported account types** select the option that matches your organization's security policy - 7. In the **Redirect URI** section select: - - - **Web** platform - - Add ``http://localhost:30081/callback`` for sandbox or ``https:///callback`` for other Flyte deployment types - - 9. Click on **Register** - 10. Once created, click on the registered app and go to the **Certificates and secrets** section - 11. Go to **Client secrets** and create a **New client secret** - 12. Enter a description and an expiration policy - 13. Take note of the secret **Value** as it will be used in the Helm chart - - For further reference, check out the official `Azure AD Docs `__ on how to configure the IdP for OpenIDConnect. + Microsoft Entra ID (Azure AD) Setup + + 1. In the Azure portal, open Microsoft Entra ID from the left-hand menu. + 2. From the Overview section, navigate to App registrations > + New registration. + - Under Supported account types, select the option based on your organization's needs. + 3. Configure Redirect URIs + - In the Redirect URI section: + - Choose Web from the platform dropdown. + - Enter the following URIs based on your environment: + - Sandbox: http://localhost:30081/callback + - Production: https:///callback + 4. Obtain Tenant and Client Information + - After registration, go to the app's Overview page. + - Take note of the Application (client) ID and Directory (tenant) ID—you’ll need these in your Flyte configuration. + + 5. Create a Client Secret + - From the Certificates & Secrets tab, click + New client secret. + - Add a Description and set an Expiration period (e.g., 6 months or 12 months). + - Click Add and copy the Value of the client secret— it will be used in the helm values. + + 6. If the Flyte deployment will be dealing with user data, set API permissions: + - Navigate to API Permissions > + Add a permission. + - Select Microsoft Graph > Delegated permissions, and add the following permissions: + ``email`` + ``openid`` + ``profile`` + ``offline_access`` + ``User.Read`` + + 7. Expose an API (for Custom Scopes) + - In the Expose an API tab: + - Click + Add a scope, and set the Scope name (e.g., access_flyte). + - Provide a Consent description and enable Admin consent required and Save. + - Then, click + Add a client application and enter the Client ID of your Flyte application. + + 8. Configure Mobile/Desktop Flow (for flytectl) + - Go to the Authentication tab, and click + Add a platform. + - Select Mobile and desktop applications. + - Add following URI: ``http://localhost:53593/callback`` + - Scroll down to Advanced settings and enable Allow public client flows. + + 9. Update Flyte Configuration + - Use the following values in your Flyte Helm chart or configuration files: + - Client ID: + - Client Secret: + - Tenant ID: + - Redirect URI: https:///callback + + For further reference, check out the official `Azure AD Docs `__ on how to configure the IdP for OpenIDConnect. .. note:: Make sure the app is registered without `additional claims `__. - The OpenIDConnect authentication will not work otherwise, please refer to this `GitHub Issue `__ and `Azure AD Docs `__ for more information. + **The OpenIDConnect authentication will not work otherwise**, please refer to this `GitHub Issue `__ and `Azure AD Docs `__ for more information. Apply OIDC Configuration @@ -263,6 +297,7 @@ Apply OIDC Configuration - "*" allowedHeaders: - "Content-Type" + auth: appAuth: thirdPartyConfig: @@ -357,34 +392,34 @@ Apply OIDC Configuration clientSecret: "" clientId: flytepropeller -.. note:: +8. Save and exit your editor. - For `multi-cluster deployments `__, - you must add this Secret definition block to the `values-dataplane.yaml` file. - If you are not running `flytepropeller` in the control plane cluster, you do not need to create this secret there. +9. Upgrade your Helm release with the new configuration: - 8. Save and exit your editor. +.. prompt:: bash $ - 9. Upgrade your Helm release with the new configuration: + helm upgrade flyteorg/flyte-binary -n --values .yaml - .. prompt:: bash $ +10. Verify that the `flytepropeller`, `flytescheduler` and `flyteadmin` Pods are restarted and running: - helm upgrade flyteorg/flyte-binary -n --values .yaml +.. prompt:: bash $ - 10. Verify that the `flytepropeller`, `flytescheduler` and `flyteadmin` Pods are restarted and running: + kubectl get pods -n flyte - .. prompt:: bash $ +11. For flytectl/pyflyte, make sure that your local config file (``$HOME/.flyte/config.yaml``) includes the following option: - kubectl get pods -n flyte +.. code-block:: yaml - 11. For flytectl/pyflyte, make sure that your local config file (``$HOME/.flyte/config.yaml``) includes the following option: + admin: + ... + authType: Pkce #change from the default `clientCred` to enable client auth without using shared secrets + ... - .. code-block:: yaml +.. note:: - admin: - ... - authType: Pkce #change from the default `clientCred` to enable client auth without using shared secrets - ... + For `multi-cluster deployments `__, + you must add this Secret definition block to the `values-dataplane.yaml` file. + If you are not running `flytepropeller` in the control plane cluster, you do not need to create this secret there. .. note::