Migrating Your Authentication Config#

Tags: Authentication, Infrastructure, Advanced

Flyte previously shipped with only a barebones OIDC setup, and relied on an external authorization server. This migration guide helps you move to Admin’s own authorization server.

Using Okta as an example, you would have previously seen something like the following:

Okta Config changes#

  • An Application (OpenID Connect Web) for FlyteAdmin itself (e.g. 0oal5rch46pVhCGF45d6).

  • An Application (OpenID Native app) for Flyte-cli/FlyteCTL (e.g. 0oal62nxuD6OSFSRq5d6). These two applications would be assigned to the relevant users.

  • An Application (Web) for FlytePropeller (e.g. 0abc5rch46pVhCGF9876). This application would either use the default Authorization server, or you would create a new one.

Admin Config Changes#

server:
# ... other settings
security:
    secure: false
    useAuth: true
    allowCors: true
    allowedOrigins:
    - "*"
    allowedHeaders:
    - "Content-Type"
    oauth:
    baseUrl: https://dev-62129345.okta.com/oauth2/default/
    scopes:
        - profile
        - openid
        - email
    claims:
        iss: https://dev-62129345.okta.com/oauth2/default
        aud: 0oal5rch46pVhCGF45d6
    clientId: 0oal5rch46pVhCGF45d6
    clientSecretFile: "/Users/ytong/etc/secrets/oauth/secret"
    authorizeUrl: "https://dev-62129345.okta.com/oauth2/default/v1/authorize"
    tokenUrl: "https://dev-62129345.okta.com/oauth2/default/v1/token"
    callbackUrl: "http://localhost:8088/callback"
    cookieHashKeyFile: "/Users/ytong/etc/secrets/hashkey/hashkey"
    cookieBlockKeyFile: "/Users/ytong/etc/secrets/blockkey/blockkey"
    redirectUrl: "/api/v1/projects"
    thirdPartyConfig:
        flyteClient:
        clientId: 0oal62nxuD6OSFSRq5d6
        redirectUri: http://localhost:12345/callback

After version 0.13.0 of the platform, you can still use the IdP as the Authorization Server if you wish. That configuration would now become:

server:
# ... other settings
security:
    secure: false
    useAuth: true
    allowCors: true
    allowedOrigins:
    - "*"
    allowedHeaders:
    - "Content-Type"
auth:
    authorizedUris:
        # This should point at your public http Uri.
        - https://flyte.mycompany.com
        # This will be used by internal services in the same namespace as flyteadmin
        - http://flyteadmin:80
        # This will be used by internal services in the same cluster but different namespaces
        - http://flyteadmin.flyte.svc.cluster.local:80
    userAuth:
        openId:
            # Put the URL of the OpenID Connect provider.
            baseUrl: https://dev-62129345.okta.com/oauth2/default # Okta with a custom Authorization Server
            scopes:
                - profile
                - openid
                - offline_access # Uncomment if OIdC supports issuing refresh tokens.
            # Replace with the client id created for Flyte.
            clientId: 0oal5rch46pVhCGF45d6
    appAuth:
        # External delegates app auth responsibilities to an external authorization server, Internal means FlyteAdmin does it itself
        authServerType: External
        thirdPartyConfig:
            flyteClient:
                clientId: 0oal62nxuD6OSFSRq5d6
                redirectUri: http://localhost:12345/callback
                scopes:
                - all
                - offline

Specifically,

  • The original oauth section has been moved two levels higher into its own section and renamed auth but enabling/disabling of authentication remains in the old location.

  • Secrets by default will now be looked up in /etc/secrets. Use the following command to generate them:

    flyteadmin secrets init -p /etc/secrets

    This will generate the new cookie hash/block keys, as well as other secrets Admin needs to run the Authorization server.

  • The clientSecretFile has been moved to /etc/secrets/oidc_client_secret so move that there.

  • claims has been removed, just delete that.

  • authorizeUrl and tokenUrl are no longer necessary.

  • The baseUrl for the external Authorization Server is now in the appAuth section.

  • The thirdPartyConfig has been moved to appAuth as well.

  • redirectUrl has been defaulted to /console. If that’s the value you want, then you no longer need this setting.

Propeller Config Changes#

You might have a configuration section that looks like this:

admin:
  endpoint: dns:///mycompany.domain.com
  useAuth: true
  clientId: flytepropeller
  clientSecretLocation: /etc/secrets/client_secret
  tokenUrl: https://demo.nuclyde.io/oauth2/token
  scopes:
  - all

This can now be simplified to:

admin:
  endpoint: dns:///mycompany.domain.com
  # If you are using the built-in authorization server, you can delete the following two lines:
  clientId: flytepropeller
  clientSecretLocation: /etc/secrets/client_secret

Specifically,

  • useAuth is deprecated and will be removed in a future version. Auth requirement will be discovered through an anonymous admin discovery call.

  • tokenUrl and scopes will also be discovered through a metadata call.

  • clientId and clientSecretLocation have defaults that work out of the box with the built-in authorization server (e.g. if you setup Google OpenID Connect).

Flyte-cli Config Changes#

You need these two configs set:

FLYTE_PLATFORM_HTTP_URL=http://localhost:8088 FLYTE_CREDENTIALS_CLIENT_ID=0oal62nxuD6OSFSRq5d6 flyte-cli ...

FLYTE_PLATFORM_HTTP_URL is used because flyte-cli uses only gRPC to communicate with Admin. It needs to know the HTTP port (which Admin hosts on a different port because of limitations of the grpc-gateway library). flyte-cli uses this setting to talk to /.well-known/oauth-authorization-server to retrieve information regarding the auth endpoints . Previously this redirected to the Okta Authorization Server’s metadata endpoint. With this change, Admin now hosts its own (even if still using the external Authorization Service).