AWS ID Prefixes: What AWS Doesnt Cover is What You Need to Know
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.
