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.

Okta Config changes#

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

  • 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#

After Flyte version 0.13.0, you can still use the IdP as the Authorization Server if you wish.

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

To summarize the changes between pre-v0.13.0 and post-v0.13.0:

  • 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#

Similarly, there are FlytePropeller config changes to be aware of.

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

To summarize the changes between pre-v0.13.0 and post-v0.13.0:

  • 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).