Flyte Admin ships with a canonical implementation of OAuth2, integrating seamlessly into an organization’s existing identity provider. At Lyft, we use Okta as the IDP, but if you have issues integrating with another implementation of the OAuth server, please open an issue.
While the most obvious interaction with the Flyte control plane is through the web based UI, there are other critical components of Flyte that also need to be considered. These components should be thought of as third-party services even though the Flyte codebase provides them.
Principal amongst these is the Flyte CLI. This is the command-line entrypoint to Flyte Admin and is used by both administrators and users more comfortable in the command line, or are running in a headless OS.
The IDP application corresponding to the CLI will need to support PKCE.
Direct Client Access¶
The gRPC client provided by the Flyte IDL, or direct calls to the HTTP endpoints on Admin from within a running script are ways that we have seen users hit the control plane directly. We generally discourage this behavior as it leads to a possible self-imposed DOS vector, as they are generally made from within a running workflow itself. For instance, a Flyte task can fetch the definition for a launch plan associated with a completely different workflow, and then launch an execution of it. This is not the correct way to launch one workflow from another but for the time being remains possible.
Flyte Admin authentication is implemented using the authorization code flow.
Flyte Admin will require that the application in your identity provider be configured without PKCE and with a client secret. It should also be configured with a refresh token.
If your organization does any automated registration, then you’ll need to authenticate with the basic authentication flow (username and password effectively) as CI systems are generally not suitable OAuth resource owners. After retrieving an access token from the IDP, you can send it along to Flyte Admin as usual.
Flytekit configuration variables are automatically designed to look up values from relevant environment variables. To aid with continuous integration use-cases however, Flytekit configuration can also reference other environment variables. For instance, if your CI system is not capable of setting custom environment variables like
FLYTE_CREDENTIALS_CLIENT_SECRET but does set the necessary settings under a different variable, you may use
export FLYTE_CREDENTIALS_CLIENT_SECRET_FROM_ENV_VAR=OTHER_ENV_VARIABLE to redirect the lookup. A
FLYTE_CREDENTIALS_CLIENT_SECRET_FROM_FILE redirect is available as well, where the value should be the full path to the file containing the value for the configuration setting, in this case, the client secret. We found this redirect behavior necessary when setting up registration within our own CI pipelines.
The following is a listing of the Flytekit configuration values we set in CI, along with a brief explanation where relevant.
FLYTE_CREDENTIALS_CLIENT_SECRETWhen using basic authentication, this is the username and password
export FLYTE_CREDENTIALS_AUTH_MODE=basicThis tells the SDK to use basic authentication. If not set, Flytekit will assume you want to use the standard OAuth based three-legged flow.
export FLYTE_CREDENTIALS_AUTHORIZATION_METADATA_KEY=textAt Lyft, we set this to conform to this header config on the Admin side.
export FLYTE_CREDENTIALS_SCOPE=textWhen using basic authentication, you’ll need to specify a scope to the IDP (instead of
openid, as that’s only for OAuth). Set that here.
export FLYTE_PLATFORM_AUTH=TrueSet this to force Flytekit to use authentication, even if not required by Admin. This is useful as you’re rolling out the requirement.