Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
List of AWS Service Principals
Copy link

Copy link

AppRunner service builder: -

Copy link

rrrix commented Sep 23, 2022

I have tried to find examples of aws:PrincipalServiceName in use but there are none. The IAM user guide has no results for this condition key. Do you have any examples I can refer to please?

@shortjared I recommend to use as the ground truth. The folder name is the service name. It is how AWS manage their SDK.

To @MacHu-GWU and anyone else who doubts the purpose and value of this gist: Unfortunately, there is actually no publicly available "ground truth" as you say for most aspects of AWS IAM data codified in a machine-readable format - including AWS Service Principals. This thread in the AWS CDK project has an excellent discussion on the topic, albeit relating to AWS Service Names and IAM Action prefixes - but the point is the same.

Interestingly, AWS IAM API Actions (e.g. svc:Action) are one of the few things that has a publicly available machine-readable format.

A couple of examples of why this list is so, so valuable, and cannot (currently) be programmatically generated:

  • The boto service-2.json definition for sso-oidc declares the values endpointPrefix: oidc, signingName: awsssooidc, serviceId: SSO OIDC and /sso-oidc/ in the file path, but the Service Principal is
  • The boto service-2.json definition for sso declares the values endpointPrefix: portal.sso, signingName: awsssoportal, serviceId: SSO and /sso/ in the file path, but again the Service Principal is...
  • The boto service-2.json definnition for sso-admin declares the values endpointPrefix: sso, signingName: sso, serviceId: SSO Admin and /sso-admin/ in the file path, but the Service Principal is WHAT THE HELL AMAZON!? 😡
  • SES has endpointPrefix: email, serviceId: SES and signingName: ses, has IAM Actions prefixed with email: and the Service Principal is

I have even more examples, but I think you get the idea. Clearly there is no consistency with regard to machine-readable resources - we cannot depend on file names, or SDK service definition file content.

We can however generally depend on AWS Documentation, but that isn't usually easily machine-readable.

I've personally spoken to many AWS Service Engineers - (who work or worked for Amazon!) - who couldn't explain why IAM is the way IAM is. It's just the way it is. My hypothesis, after years of unofficial research on the subject and despite the clear need and desire from their customers, is that there was never an "official" internal requirement for a standardized, unified and consistent convention for identifiers, tokens, service endpoint prefixes, API grammar, or other terminology for API definitions, authorization policies, or in this case, Service Principals. Perhaps someday, an IAM product/service owner in AWS will see this gist and realize their mistake and finally publish a definitive resource for us (hint, hint) 😉.

Thank you to everyone who contributes to this gist. You're helping build great things one Service Principal at a time 👏

Copy link

Copy link

Olekidh commented Dec 12, 2022

When I was importing resources from AWS in terraform, I observed some additional service principals:

Copy link is missing. It's a new service which recently added

Copy link

Audit Manager service principal, which is .

Copy link

f0xtek commented Jan 13, 2023 has recently been added for the fairly new Network Manager Reachability Analyzer. Now supports delegated administrator functionality for cross-account analyses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment