AWS Use Cases & AuthN Options
AWS cloud has become an essential part of compute for any organization. Authentication is the stepping stone for access any of their services.
However, the challenge is that AWS provides multiple options for authN and it becomes sometimes hard to choose the right option.
In this article, we will discuss various available options, which will serve as a usage guideline. Details about each of the auth methods have been linked to AWS documentation for reference.
TLDR; Pls refer the picture below.
Human User
If a human user wants to authenticate to console they can use AWS native Identity Center or an external Identity Provider such as Azure AD, G-Suite etc. to authenticate themselves.
Other less secure option is to use Access Keys. Since they are static in nature and can be compromised easily, they should be avoided as much as possible. In case they cannot be then source IP based restrictions can be considered as a compensating control.
EC2 Workloads
If an application is running inside EC2 and wants to leverage other AWS services then Instance Profile is the way to go. Instance profile represents an EC2 instance principal much like IAM user represents a human user.
Instance Profiles are also attached to IAM role, which define what this EC2 is allowed to do (AuthZ).
S3 Contents
If the use case demands sharing of S3 contents with others then there are multiple options available. Opening S3 bucket contents to public may not be the best idea.
Pre-signed URL can be leveraged to share content access. An expiry date can be mentioned along with other access conditions to control access.
There are 2 other methods of providing access to S3 contents via CloudFront — Origin Access Identity (OAI) & Origin Access Control (OAC)
OAI is the legacy option and should be avoided because OAC supports SSE-KMS, All HTTP methods and most importantly all regions.
Auth for CI/CD Piepeline
For building CI/CD Pipelines to automate IaC (Infrastructure as Code) deployment you need to give your pipeline runner permission to deploy those resources.
The legacy way is to create static Access Keys and save them in pipeline. That has lot of management drawbacks like rotation, secure storage and proliferation of keys.
Using OIDC provider is an elegant way to handle this use case.
External Workloads
If you have workloads running outside AWS ecosystem but have a need to use AWS services then IAM Role Anywhere is the best available option.
Fundamentally it is a X.509 certificate based authentication, where certificate CA has a trust relationship with say AWS Private CA.
3rd Party AWS Accounts
This is a common use case for using vendor tools like security scanning, CSPM etc.
A Cross Account Role option should be leveraged to provide access to the users in a 3rd party’s AWS account.
Conclusion
Here we have discussed only authentication use cases & options however each of these options (except S3 access) have an IAM Role configured for authorization purposes.
The guidance is to have these role permission tightly coupled with business needs only.
