Feedback: Service/Service-linked roles and exclusion micromanagement

[jcmcken]

Summary

Currently, IAM condition keys like aws:PrincipalIsAWSService and aws:ViaAWSService (and related keys) don't work for service roles or service-linked roles. In fact, no condition keys work for those cases. This means, as this data perimeter sample implies, that you need to micromanage exclusions to SCPs, RCPs, or any other location where perimeters can be established. Specifically, it means either that you need to hard-code excluded principal names into your RCPs/SCPs, or you need to use some mechanism (like in this data perimeter sample) where admins need to go in and specifically tag resources or principals to exclude them.

But in practice, none of these options work well.

Scenario

Imagine there's a tenant account in an AWS organization that creates service role to access some AWS resource they provisioned in the same account. Assume there's an RCP in this org that implements a network data perimeter such that no resource can be accessed except through defined VPC endpoints or CIDR blocks. The tenant's resource and role will not work correctly due to this RCP. To make things functional, an org admin would need to log into this account and tag one or both of the resource and the principal to exclude them.

First Problem: Administrative Overhead

First consider just the operational burden.

In practice, the tenant likely provisioned their resources through some mechanism such as CDK or Terraform using their own permissions. If an org admin attempts to rectify this issue by adding the exclusion tags by hand, these provisioning tools will attempt (and fail) to revert these modifications. The tenant would then need to implement some code to prevent the reversion.

So you can see there's a very cumbersome workflow here:

• Tenant provision resources
• Tenant tries to use resources, but gets RCP denials
• Tenant raises a support ticket with the org admins
• Org admins come in and add exclusion tags and the resource begins working correctly
• Later on (perhaps much later on), the tenant re-runs their cloud automation (e.g. Terraform) and it shows there's a reversion of the exclusion tag, which they have no understanding of. They try to apply the automation but it fails.
• Tenant re-raises a support ticket.
• Org admin informs tenant they need to exclude the tag in question from reversion
• Tenant modifies their code

When there are dozens or even hundreds of teams in an org, this presents a rather large administrative burden. Communicating these minutiae to a large org, most of whom probably have little to no cloud experience, is daunting.

Second Problem: Security

Now consider a completely different problem: the security implications of excluding a principal or a resource from data perimeter checks. Such exclusions seem to defeat the purpose of the data perimeter, and in fact endanger other resources within the perimeter.

Let's imagine I exclude a principal from the data perimeter checks. Then let's imagine that somehow the credentials for that principal leak on the open Internet (say to a Github repo) -- a not uncommon occurrence. Since the principal is excluded, it can now potentially be used by anyone outside of the data perimeter to access resources in the org. In such cases, it may even be possible (depending on what services we're talking about and what permissions this service or service-linked role has) to move laterally within the data perimeter to affect principals or resources which do not have exclusions.

Conclusion

It seems like AWS needs to support some other mechanism for allowing service roles to access data perimeter protected resources than data perimeter exclusions. For example, add a boolean condition key called aws:ControlPlane that indicates if a request came from AWS assuming a service role to act on a resource. Then you could build an RCP that says "deny access if the request doesn't come from approved VPC endpoints and doesn't come from approved CIDRs and doesn't come from AWS control plane" and not have to manage individual exclusions. But I have no idea what the technical implications of this suggestion are.

[liwadman]

Hey Jon, thanks for your feedback. We'd definitely be interested in talking more and would encourage you to reach out to us through your account team to facilitate that, but none of your high level points come as a surprise to us. Data perimeters is a top priority for AWS Identity and we're working on lots of different features to make applying one easier. We'd be very happy to discuss that as well as gather some more feedback from you.