Hello! I'm wondering if someone would be able to offer me a bit of guidance around policies 🙏 The scenario we're in is a service that has principals made up of service accounts and real people. All principals are supplied by an oauth2 service and follow the same schema. I'm looking for guidance on best practices here. What I've considered so far is: - A separate principal policy for each service account across each environment. From a scalability POV that scared me, as the UUIDs could change, or at least are not known until they are provisioned, so would require actively managing. The IDs also vary across environment, so we would need a separate policy for each one. - Use roles and assign unique roles to the SA. My concern here is that we did this in our last access management solution and it resulted hundreds of very granular permissions, which was hard to manage. I'm sure there's an option that I've missed and I'm not seeing 🙈

Hello fellow Andy! I agree that a principal policy per service account is unlikely to be the way to go. My initial take would be that you would define a set of roles that can be held by service accounts, and then when you create a service account in your identity provider you allocate it the specific set of roles it needs to define its access level. That way you don't have a unique role per service account so adding a new service account would not require any changes to your policies (assuming that its permissions can be described by a set of existing roles). Does that sound reasonable?

Thanks Andrew, that's what I suspected. It's an overhead, but manageable. It would be great if we were to be able to make principal policies based on their attributes. I guess we can do that in a resource policy already, but it's just organisation 🤷‍♂️

Yeah for stuff based on principal attributes, often the answer is to use derived roles.

That may be the compromise then, I can safely identify the SA for that exact service based on a few of the attributes. thanks!

Nice 🙌🏼