[Docs] Document supported authType values

[davidmirror-ops]

Description

A recurring question from users has to do with how to do auth for particular scenarios, including:

• Headless (machines with no GUI)
• CI/CD systems

The current auth documentation doesn't mention that there are options other than Pkce that would support those scenarios.

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[dosubot]

Hey @davidmirror-ops! Great to see you diving into another adventure with us. Hope you're ready for some more fun and learning! 🚀

Thank you for bringing this to our attention. It's indeed important to have clear documentation on the supported authType values and how to configure them for different scenarios, including headless machines and CI/CD systems.

Currently, the Flyte codebase supports two authType values as defined in the flyteadmin/auth/config/config.go file:

• AuthorizationServerTypeSelf: FlyteAdmin acts as the authorization server.
• AuthorizationServerTypeExternal: An external authorization server is used, such as Okta.

For headless machines and CI/CD systems, the client_credentials grant type can be particularly useful. This grant type allows an application to authenticate and obtain an access token directly, without a user's interaction, by presenting its own credentials. Here's an example of how a client (flytepropeller) is configured with the client_credentials grant type in the config.go file:

"flytepropeller": {
    ID:            "flytepropeller",
    Secret:        []byte(`$2a$06$d6PQn2QAFU3cL5V8MDkeuuk63xubqUxNxjtfPw.Fc9MgV6vpmyOIy`), // Change this.
    RedirectURIs:  []string{"http://localhost:3846/callback"},
    ResponseTypes: []string{"token"},
    GrantTypes:    []string{"refresh_token", "client_credentials"},
    Scopes:        []string{"all", "offline", "access_token"},
},

To configure the client_credentials grant type for headless machines and CI/CD systems, you would typically need to:

1. Identify or create a client ID and secret.
2. Configure Flyte to use the client_credentials grant type.
3. Set the client ID and secret in the configuration.
4. Specify scopes if necessary.
5. Set the audience if required by your OAuth provider.
6. Configure additional OAuth parameters as needed.
7. Apply the configuration to your Flyte deployment.
8. Test the configuration to ensure that your headless machines or CI/CD systems can authenticate using the client_credentials grant type and access Flyte as expected.

Please note that the provided context does not include explicit instructions or flags for setting the client_credentials grant type directly. In practice, configuring OAuth2 and the client_credentials grant type involves setting the client ID, client secret, and other OAuth-related parameters according to the authentication provider's requirements and Flyte's configuration capabilities. If Flyte or the OAuth provider requires additional specific steps for client_credentials, refer to their respective documentation.

I hope this information helps. If you have further questions or need more specific guidance, please provide additional details about your authentication provider and the specific scenarios you're trying to support.

Sources

• flyteadmin/auth/config/config.go
• flyteadmin/auth/config/config_flags.go

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[gShahr]

I am interested in working on this. Could you assign this issue to me?

[davidmirror-ops]

@gShahr sure! please let us know soon any questions you may have. Thanks!