@ancient-wolf-19325 how to implement Flyte control plane RBAC?

As of now, Flyte open source does not provide built-in Role-Based Access Control (RBAC) for the control plane. All authenticated users can access all projects and domains, and there is no official mechanism to restrict user actions to specific projects or domains. There are ongoing discussions and proposals to add RBAC and project/domain isolation, but these features are not yet available in the open source version. Some organizations implement custom solutions or use separate Flyte environments for access boundaries, but this is not natively supported or documented as a standard approach. For the latest status, see the related GitHub issue and open RFC/PR. If you need project-level isolation, you may need to implement custom middleware or external authorization (e.g., with Open Policy Agent), or wait for the upstream RBAC feature to be merged. The managed Union Cloud offering does include RBAC, but this is not part of open source Flyte. For more details, see the discussion on project isolation and RBAC feature request. Would you like a step-by-step breakdown of the current proposals and possible workarounds? Sources: - Flyte Project isolation - RFC: Flyte Admin RBAC + Project/Domain Isolation - https://github.com/flyteorg/flyte/issues/3909 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 Yes curious about the possible workarounds

The main workaround for Flyte control plane RBAC is to deploy separate Flyte environments (clusters) for each access boundary, effectively isolating users by environment. This approach is commonly used since Flyte does not natively support per-project RBAC in open source. Another workaround is to implement custom middleware or interceptors in a private fork of FlyteAdmin, which checks user identity claims and restricts access to specific projects/domains, but this requires ongoing maintenance and careful tracking of new API endpoints. Some organizations also explore integrating external authorization systems (like Open Policy Agent), but there is no official or documented integration for this in Flyte OSS. These workarounds have limitations: environment-based isolation increases operational overhead, and custom middleware is error-prone and not future-proof. The community is actively discussing RBAC and project isolation, but until an official solution is merged, these are the only practical options. For more, see the project isolation issue, custom fork discussion, and RBAC feature request. Would you like a detailed step-by-step on implementing a custom middleware approach? Sources: - Flyte Project isolation - RFC: Project isolation custom fork - https://github.com/flyteorg/flyte/issues/3909 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes

To implement custom RBAC middleware for Flyte control plane, you would typically fork the FlyteAdmin service and add a gRPC/HTTP middleware that inspects incoming requests, extracts user identity (from authentication tokens), and enforces project/domain access policies. Here’s a step-by-step outline based on community discussions and private forks: 1. Fork FlyteAdmin: Clone the Flyte repository and focus on the FlyteAdmin service, which handles all control plane API requests. 2. Add Middleware: Implement a middleware/interceptor for gRPC and HTTP endpoints. This middleware should: - Extract the user’s identity and claims from the authentication token (e.g., JWT). - Map claims (such as group or project membership) to allowed Flyte projects/domains, using a configuration file. - For each API request, check if the user is authorized to access the requested project/domain. - Reject unauthorized requests with an appropriate error. 3. Update All Endpoints: Ensure the middleware is invoked for all relevant endpoints (e.g., workflow/task registration, execution, listing). This may require explicitly listing endpoints, as there is no generic way to cover all request types. 4. Maintain Configuration: Keep the claim-to-project mapping up to date as new projects or users are added. Optionally, implement a default mapping for new projects. 5. Test and Deploy: Thoroughly test the middleware to ensure it blocks unauthorized access and does not break legitimate workflows. Deploy the custom FlyteAdmin in your environment. Caveats: - This approach is manual and brittle: new API endpoints must be added to the middleware, or they may bypass authorization. - Upstream changes to FlyteAdmin may require you to rebase and update your fork. - This is not officially supported and may not scale well for large organizations. For more details and real-world experiences, see the project isolation RFC and discussion and project isolation issue. Sources: - RFC: Project isolation custom fork - Flyte Project isolation 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.