Question to the more DevOps/SecOps oriented people around here. Please read with attention as this a bit involved, and I may be mis-terming things. So, we want to allow our developmers to deploy their services to K8S, in addition we want them to be able to provision AWS resources that "belong" to the service like an SQS queue for example. We know generally how we want to do this (actual implementation is not important - I can elaborate if anyone wants - still on the design board - so it can change as well) The question is about security specifically IAM roles and policies. We want each service to have its own service account in K8S, and connect each account to a IAM role (per service account). Again, this we know how to do. Now, we want each such role (execution role) to be able to access the services resources, and shared resources that it is allowed to and we don't want it to be able to access other resources. The affinity is pretty simple - because we "know" which resources belong to which service, same for shared (we "know" they are shared) However, SecOps want to be able to review and approve/reject IAMpolicies written by developers, which can cause an approval bottleneck - which we want to avoid. Do you have a situation like this? How is it solved by you? Use case for example An existing SNS Topic, existing service wants to subscribe to the topic, so we want to provision an SQS Queue and subscribe it to the topic. SecOps demand that the service role should have explicit permissions to the Queue resource, so during d provisioning we need to create/use and attach policies to the resource that reference the role... Again, the issue is that SecOps do not want Roles or Policies created without review. But if a role or Policy is approved (i.e. exists in the AWS account) - you can attach them to resource and role Ideas? Or am I completely unclear and all over the place? We considered doing the role and policy creation in a separate process, like I did previously - but the fact that the permission policy has to refer to both principal and resource (because the access right is not * on any of those), and creating policies per service is also not realistic (and poses an issue on its own) - so is there a way to attach a policy with "rules" - but so that it's not a dynamic policy (which is also not allowed without review)

Are you already using something like Crossplane or k8 Cluster API to create your infra resources? I know you said not to This seems more of a process problem, you understand the technical solutions available to you. Kinda seems like the solutions align with how the roles are approved, so: 1. Code based dynamic policies... I know you said they need approval, but creating a specific core module that's a dependency to your applications, with a deployment process SecOps approves... 2. Using a platform deployment process that allows teams to create their infra resources together with their app, so roles are aligned with IaC, and SecOps can observe them through the central deployment process... Existing and shared resources still could be tricky, be centrally managed at least. Or even some combination of these perhaps. I'd also say I've seen customers run into Role account quotas using Service Account strategy, especially with a role per service.

Well, we are now working on this new platform, some resources are already provisioned this way, but only a few. It's Def mostly a process question, but I think we have that ok - we know the steps and when each part/step is executed, it's more of the right way to implement in the AWS world - can such a thing be done (static policies with dynamic resource provisioning) Regarding having security review the code and approve dynamic policy creation - that one we know - but SecOps are really set against, mostly because they are afraid of someone using these permissions outside of our code... Same for creating the roles - they want this centralized and under their control - which would be manual and ticket based - which isn't good enough for us... We need to work with an approved SecOps procedure in our code, and with a closed set of permissions -

yes, but there is a hard quota of 5000 roles per account https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities

I hope we never reach that number - at least regarding different services. However there is a thought to provide the same granularity of control for lambda/cloud functions - and those + all the other roles might get there fast...

@Moshe Eshel there's a guy I met in Israel, Shimon Tolts (he's also an AWS hero, IIRC). I think his company is doing policy management via Github. Worth checking them out, and perhaps talking to him (he's nice, smart and helpful).

We need to work with an approved SecOps procedure in our code, and with a closed set of permissions

Perhaps in that case what @Gwen Shapira is suggesting would be a good option... Simply make policy management it's own pipeline with approval? Certainly worth a look.

Regarding having security review the code and approve dynamic policy creation - that one we know - but SecOps are really set against, mostly because they are afraid of someone using these permissions outside of our code...

Understood. I'd argue the exposure with ABAC is limited, but a non-zero exposure for sure (and ABAC role could still be assumed by rogue code). My Tel Aviv based co-worked @Alex Pulver just did this sample on Github... Not sure ABAC would convince your SecOPS, just an FYI.

My experience is that very few SecOps people understand ABAC 😕

Looking at the AWS IAM API, it seems that ABAC allows some dynamism (you can change permissions without changing roles or policies) If I understand correctly I can create a policy that allows access to any role/user with a tag/label to access a resource (also tagged or not) Better than adding thousands of copies of the same policy with different resource names... But - I don't see how it resolves the underlying issue - because this makes permissions dynamic, then now the issue is of adding the tags/labels outside the approved code 🥴

@Moshe Eshel we manage the tags/labels in Pulumi, so it is part of our Infra-as-Code. If we had SecOps guys, we'd have them review the changes to these scripts (they would probably need that anyway, all our network stuff is there)

I think it should, if they agree to use ABAC it could be a good solution for this...

ABAC is definitely still dynamic you are right, just less so that other forms of Dynamic Policies. You can't assume a ABAC role without replacing the variables, so they can be narrowly scoped.. You can only read the SQS queue if the queue is tagged with "tenant-id". So code could still accidentally (or maliciously) assume your role to get access to a different queue if you knew some other tenant-id...

Which is why tenant-id should always be uuid and never a sequence, but thats another discussion 😉

I get it, so two problems remain 1. Convincing our SecOps people to adopt this 2. Waiting for AWS to make ABAC work on some more resources (such as SQS and SNS) that don't seem supported yet ☹️ Of course this link might be a little behind https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

I think the obstacle is probably SecOps... There are definitely services you can't use ABAC with, but I believe you can with SQS and SNS

Yeah, I'll try tomorrow in my sandbox account... At least it fits my mental model so I get it and happy that my mental model is supported by implementation reality 🤓 Yay

Hi :) Note that ABAC doesn't necessarily mean using both identity-based and resource-based policy. You can use ABAC perfectly fine with identity-based policy only. Here's an example for SNS: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-wheretouse

Thanks @Alex Pulver you saved me a test 🙂 like I wrote, I don't the link I sent above was very up-to-date... ABAC stands on it's own for sure, but in our case we are using Role based to identify users/services, so it works well to combine - because we have uses for both. since they mix well - better for all.

@Moshe Eshel -would love to hear how you solved it? I liked OPA and the ability to review including testing the policies before deploying that Styra provides. Although it can be a bit more involved