synint91 commented on issue #441: URL: https://github.com/apache/polaris/issues/441#issuecomment-3748251968
Thanks @adutra > Migrating to External Principals: afaict this would not cause corruption or duplication, but the existing principal entities persisted in your database would become obsolete and serve no purpose. I think this approach makes sense for my use case, especially since it closely aligns with Snowflake’s design principles. I have a couple of questions about this approach. We also support an internal realm for creating service-account–type principals and binding them to principal roles. This is primarily used for long-running batch jobs (for example, Spark jobs) that perform client-credentials grant flows, rather than authorization-code or silent device flows, which are typically used by human users interacting through Azure AD. For example, in the internal realm, in addition to Azure AD–synced human users, we also create service-account principals that are mapped 1:1 to roles (e.g., a data_engineer_sp_act principal ID mapped to the data_engineer principal role), and so on. What are your thoughts on the best way to support external principals for batch workloads? Specifically: 1. Can an external principal still support batch workloads that require a client-credentials grant flow, similar to what the internal realm supports by default ? 2. Or is it better to migrate these service-account principals to Azure AD and enforce the client-credentials grant flow there instead ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
