@ancient-wolf-19325, flyte-admin-base-config/server.yaml sample configuration for external auth server as okta ??

For configuring Flyte with an external authorization server like Okta, you can refer to the following sample configuration for `server.yaml`:

auth:
  appAuth:
    authServerType: External
    externalAuthServer:
      allowedAudience: <https://flyte.my.domain>
      baseUrl: <https://xxx.okta.com/oauth2/xxx>
      metadataUrl: .well-known/oauth-authorization-server
    thirdPartyConfig:
      flyteClient:
        clientId: xxx
        redirectUri: <http://localhost:53593/callback>
        scopes:
        - offline
        - all
  authorizedUris:
  - <https://flyte.my.domain>
  - <http://flyteadmin:80>
  - <http://flyteadmin.flyte.svc.cluster.local:80>
userAuth:
  openId:
    baseUrl: <https://xxx.okta.com/oauth2/xxx>
    clientId: xxx
    scopes:
    - profile
    - openid
    - offline_access

This configuration sets up Flyte to use Okta as an external authorization server. Make sure to replace placeholders with your actual Okta details. Would you like more details on any specific part of this configuration? Sources: - https://discuss.flyte.org/t/12111041/tldr-403-forbidden-errors-using-flytectl-oidc-and-oauth2-ena/ - https://docs.flyte.org/en/latest/deployment/cluster_config/auth_migration.html#panel-0-Pj0gdjAuMTMuMA%3D%3D 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 After configuring external auth server as okta when we call flyteadmin POST /executions api which application access token we need to send as part of athentication header? is it flytepropeller application client_id created in okta or any other ?

It seems likely that when calling the FlyteAdmin

POST /executions

API, you would use the access token associated with the

flytepropeller

application client ID created in Okta. This is because

flytepropeller

is typically configured to authenticate using the client credentials flow, which is suitable for non-user-facing services like FlytePropeller that need to interact with FlyteAdmin. Would you like more details on how to configure or obtain the access token for

flytepropeller

? Sources: - https://docs.flyte.org/en/latest/deployment/cluster_config/auth_setup.html#custom-authorization-server - https://github.com/flyteorg/flyte/issues/5021 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325, this is the config which u shared for okta

auth:
  appAuth:
    authServerType: External
    externalAuthServer:
      allowedAudience: <https://flyte.my.domain>
      baseUrl: <https://xxx.okta.com/oauth2/xxx>
      metadataUrl: .well-known/oauth-authorization-server
    thirdPartyConfig:
      flyteClient:
        clientId: xxx
        redirectUri: <http://localhost:53593/callback>
        scopes:
        - offline
        - all
  authorizedUris:
  - <https://flyte.my.domain>
  - <http://flyteadmin:80>
  - <http://flyteadmin.flyte.svc.cluster.local:80>
userAuth:
  openId:
    baseUrl: <https://xxx.okta.com/oauth2/xxx>
    clientId: xxx
    scopes:
    - profile
    - openid
    - offline_access

here xxx under thirdPartyConfig.flyteClient which okta application client_id ?? is it flytepropeller ?

In the configuration you provided, the

clientId

under

thirdPartyConfig.flyteClient

should correspond to the client ID for the Flytectl application in Okta. This is because

thirdPartyConfig

is typically used for configuring Flytectl, which is a command-line tool for interacting with Flyte. Would you like more details on setting up Flytectl or any other part of the configuration? Sources: - https://discuss.flyte.org/t/2929022/hi-i-am-trying-to-integrate-okta-with-flyte-following-this-h/ - https://github.com/flyteorg/flyte/issues/2606 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325, pyflyte run/pyflyte register internally use which application ? flytectl, flytepropeller..etc ?

pyflyte run

and

pyflyte register

are commands provided by Flytekit, and they do not directly use

flytectl

or

flytepropeller

. Instead, they interact with FlyteAdmin to register and execute workflows.

pyflyte run

is a convenience command that packages, registers, and launches a workflow, while

pyflyte register

is used for registering workflows with FlyteAdmin. Would you like more details on how these commands work or their interaction with FlyteAdmin? Sources: - Flytekit CLI Documentation - Flyte GitHub Issue on pyflyte register 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325, i mean after enabling flyte authentication when try to do pyflyte register, it if failing . Failed with Exception <class 'RuntimeError'> Reason: Failed to get signed url for fast598a78eaf817c63ff7666203dfbe9b91.tar.gz, reason: SYSTEMUnknown error=None, cause='NoneType' object cannot be interpreted as an integer

It seems likely that the error you're encountering during

pyflyte register

is related to authentication or authorization issues, possibly due to misconfiguration in the authentication setup. This could be related to the access token or client credentials not being correctly configured or recognized by FlyteAdmin. To troubleshoot this issue, you might want to check the following: 1. Authentication Configuration: Ensure that the

clientId

and

clientSecret

for the application used by

pyflyte

are correctly configured in your FlyteAdmin and Okta settings. 2. Scopes and Permissions: Verify that the necessary scopes and permissions are granted to the application in Okta. This includes ensuring that the application has the right to request the required scopes. 3. FlyteAdmin Logs: Check the FlyteAdmin logs for any specific error messages that might provide more insight into the issue. 4. Network and Connectivity: Ensure that there are no network issues preventing

pyflyte

from communicating with FlyteAdmin. Would you like more detailed guidance on any of these steps? Sources: - Flyte GitHub Issue on Authentication - Flyte Discuss on Authentication Errors 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325, does FLYTE_INTERNAL_VERSION env have workflow version as value ??

The

FLYTE_INTERNAL_VERSION

environment variable typically contains the version of the task, not the workflow. This is because Flyte's internal environment variables are generally more focused on task-level information rather than workflow-level details. Would you like more details on how to access workflow version information or any other specific aspect? Sources: - Flyte GitHub Issue on Environment Variables - Flyte Discuss on Workflow Metadata 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes, also what is the use of FLYTE_INTERNAL_TASK_VERSION ?

It seems likely that the

FLYTE_INTERNAL_TASK_VERSION

environment variable is used to store the version of the task being executed. This versioning is crucial for ensuring that the correct version of a task is executed, especially in environments where multiple versions of a task might exist. It helps maintain consistency and reproducibility in task execution by allowing Flyte to identify and execute the specific version of a task that was registered. Would you like more details on how task versioning works in Flyte or any other related topic? Sources: - https://discuss.flyte.org/t/10243073/so-folks-i-have-a-job-thats-been-running-for-the-last-16-min/ - https://github.com/flyteorg/flyte/blob/master/flyteplugins/go/tasks/pluginmachinery/flytek8s/k8s_resource_adds.go 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 is there a way to get workflow version during execution or i mean inside a task without calling flyteadmin endpoints ??

It seems likely that accessing the workflow version directly within a task during execution without calling FlyteAdmin endpoints is not straightforward. The current Flyte environment variables and context primarily provide task-level information, such as task version, but not workflow-level details like workflow version. However, you might be able to use the

ExecutionParameters

object in Flytekit to access some execution context, though it does not explicitly include workflow version. You could potentially pass the workflow version as a parameter to tasks if it's critical for your use case. Would you like more details on how to work with

ExecutionParameters

or any other specific aspect? Sources: - Flyte Discuss on Workflow Metadata - Flyte GitHub Issue on ExecutionParameters 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes

To work with

ExecutionParameters

in Flytekit, you can access various execution context details within a task. However, as mentioned earlier, the workflow version is not directly available through this object. Here's a basic example of how you can use

ExecutionParameters

to access some execution context:

from flytekit import task, current_context

@task
def my_task():
    # Access the execution parameters
    execution_params = current_context().execution_parameters

    # Example: Accessing the execution ID
    execution_id = execution_params.execution_id
    print(f"Execution ID: {execution_id}")

    # Example: Accessing the task version
    task_version = execution_params.task_version
    print(f"Task Version: {task_version}")

    # Note: Workflow version is not directly accessible

In this example,

current_context().execution_parameters

provides access to the execution ID and task version. Unfortunately, the workflow version is not part of the available attributes. If the workflow version is critical, consider passing it as an input parameter to the task when launching the workflow. Would you like more information on how to pass parameters to tasks or any other specific aspect? Sources: - Flyte Discuss on Execution Context 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.