AWS ID Prefixes: What AWS Doesnt Cover is What You Need to Know

  • Thursday, 24 Sep 2020 3:30PM EDT (24 Sep 2020 19:30 UTC)
  • Speaker: Dan Girard

For years AWS has always prided itself on teaching you the cloud via those constructs right from the manual. Typically, as architects come to a new employer the opportunity to build a \greenfield" cloud architecture may not be there. Often, you will need to correct or adjust those current infrastructures or configurations. Having a great background on what these prefixes mean, how to deal with them will provide great dividends. From not only moving the firm's architecture forward but also during those tense times where you may be working through an investigative manner within your cloud account.

In this talk we will showcase and go over those prefixes what they mean, how you can get them. Some resource types like S3 for example allow for the use of a unique ID rather than the full principle ARN that many know and understand. We can cover why use of the unique ID is fundamentally a bad idea, and how to handle them should you run into an environment that has them.

Understanding Unique ID Prefixes

IAM uses the following prefixes to indicate what type of entity each unique ID applies to.

Prefix - Resource Type

ABIA - AWS STS service bearer token

ACCA - Context-specific credential

AGPA - Group

AIDA - IAM user

AIPA - Amazon EC2 instance profile

AKIA - Access key

ANPA - Managed policy

ANVA - Version in a managed policy

APKA - Public key

AROA - Role

ASCA - Certificate

ASIA - Temporary (AWS STS) keys

In this web series we will cover methods to diagnose, discover and rectify AROA/AGPA/AIDA unique ID's within an S3 bucket policy. Further we will show to rapidly translate an AROA/AGPA/AIDA unique ID into the AWS Principal ARN that many cloud engineers are comfortable with.