@ancient-wolf-19325 is there a way to upload workflow without using pre-signed URL?

No, Flyte's standard workflow registration and fast registration processes rely on uploading workflow code and artifacts to a blob store (such as S3, GCS, or MinIO) using pre-signed URLs generated by the Flyte control plane (FlyteAdmin). This is a core part of the architecture to ensure secure, permissioned, and reproducible artifact storage, and there is no documented method to upload workflows without using pre-signed URLs or the associated upload mechanism provided by FlyteAdmin or the CLI tools like pyflyte or flytectl. This approach is referenced in the documentation and several issues, which explain that the client receives a pre-signed URL from FlyteAdmin and uploads the workflow package to the blob store using that URL, ensuring the control plane does not require direct access to the data bucket (source, source, source). If you have a specific use case or restriction that prevents using pre-signed URLs, please clarify your requirements, as the current Flyte architecture does not support alternative upload mechanisms for workflow registration. Sources: - https://github.com/flyteorg/flyte/issues/4881 - https://github.com/flyteorg/flyte/issues/2868 - https://github.com/flyteorg/flyte/blob/master/docs/user_guide/flyte_fundamentals/registering_workflows.md 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 the main security concern of using AWS pre-signed URLs to upload files to S3 is unauthorized or unintended access due to leakage (the URL could be shared or leaked). We cannot set role/user identity based policy to constraint the permission, how do we address this security concern?

It could be possible that Flyte's use of pre-signed URLs for S3 uploads does present a risk if the URL is leaked, since anyone with the URL can upload within the allowed time window. Though I'm not entirely certain, it might be that Flyte mitigates this by generating URLs with short expiration times and only for specific, unique object keys, thus limiting the window and scope of exposure. However, Flyte does not natively support attaching user/role-based policies to pre-signed URLs themselves, as S3 pre-signed URLs are inherently bearer tokens and not tied to user identity (source). If your organization requires stricter controls, you might need to implement additional monitoring or network controls to restrict access to the URLs, or consider using a proxy or service that authenticates users before allowing uploads. There is no explicit mechanism in Flyte to bind pre-signed URL usage to a specific user or role beyond the initial request context. Sources: - https://github.com/flyteorg/flyte/issues/2868 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.