Types of Identities
IAM Users (Humans)
IAM Users represent a specific category of identity within the Amazon Web Services (AWS) ecosystem. These users are designed to grant individuals distinct access to a wide array of AWS resources and services. Each IAM User operates under a set of unique credentials, which include a username and password. This system allows for precise control over permissions, enabling organizations to manage who can access specific services and resources while ensuring security and accountability across their cloud infrastructure.
Service Accounts (Machines)
Service Accounts, in contrast, are specifically designed to facilitate interactions for machines, automated processes, and various applications. Unlike IAM users, who typically utilize usernames and passwords to gain access to the AWS console, Service Accounts operate through a different mechanism. They rely on access key pairs or security credentials that are generated from the AWS STS (Simple Token Service), rather than traditional login methods. This distinction allows for a more streamlined and secure method of authentication, suited for automated tasks and processes that require consistent and reliable access to AWS resources without the need for human intervention.
IAM Roles & Role Assumption
AWS IAM Roles serve as a vital mechanism for granting temporary access to various resources within the Amazon Web Services (AWS) environment. These roles can be assigned to a diverse range of entities, including individual users, applications, and service accounts, allowing for a flexible approach to permissions management.
One of the key benefits of utilizing IAM Roles is their effectiveness in facilitating operations such as federated access, which enables users from different identity providers to access AWS resources seamlessly, and cross-account access, allowing users in one AWS account to interact with resources in another account securely.
Additionally, by leveraging security tokens, IAM Roles significantly enhance security by eliminating the necessity for long-term credentials, thus reducing the risk of credential compromise and ensuring that access is granted only for the duration needed. This makes them an essential tool for organizations looking to maintain a robust security posture while providing the necessary access to their AWS resources.
IAM Groups
IAM Groups function as containers for multiple IAM Users, thereby simplifying the management of permissions. By assigning policies to groups, administrators can effectively control access for numerous users simultaneously. This method streamlines the process of granting and revoking permissions.
Users may belong to multiple groups, inheriting the cumulative permissions from each. This flexibility facilitates granular access control and simplifies the organization of users based on their roles or responsibilities. Groups can be created, modified, or deleted without impacting individual user accounts.
The use of IAM Groups enhances scalability and reduces administrative burdens. As organizations expand, new users can be added to existing groups, automatically receiving the appropriate permissions. This strategy ensures consistent access management and improves security by minimizing the risk of misconfigured individual user permissions.
Types of Credentials
AWS Identity and Access Management (IAM) uses specific prefixes for different types of resources and credential identifiers. Here are some of the prefixes and their corresponding resource types:
-
AIDA: AWS IAM user
-
AIPA: AWS EC2 instance profile
-
AKIA: Access key
-
ANPA: Managed policy
-
AROA: Role
-
ASCA: Certificate
-
ASIA: Temporary AWS STS keys
These prefixes help distinguish between the various types of resources and credentials managed within AWS IAM.
Custom Policies vs Managed Policies
Managed policies are designed, pre-built policies that are developed and continuously maintained by Amazon Web Services (AWS). These policies are specifically crafted to address prevalent use cases across various industries, ensuring that they remain relevant and effective. One of the key advantages of managed policies is that they are automatically updated whenever new services or API methods are introduced or removed, providing users with a seamless experience and up-to-date security measures.
In contrast, custom policies are created and maintained internally by the organizations that utilize them. This allows for a unique, flexible, and precise access control mechanism that can be meticulously tailored to meet the specific needs and requirements of the organization. By leveraging custom policies, organizations can implement more granular control over access permissions, ensuring that their security protocols align closely with their operational goals and compliance requirements.
Policies, regardless of their type, are created using JSON code. This code structure is designed to clearly define access permissions and typically looks similar to the following example. In this example, the Action specifies "What" is allowed or denied, such as listing and retrieving data from AWS S3 buckets. The Effect is a crucial component that indicates whether the action is permitted or not, represented by a boolean value of either Allow or Deny This ensures that the policy explicitly states whether the specified actions can be executed. The ‘Resource’ field is another important part of the policy, as it defines the specific AWS resources to which the policy applies. This could include particular S3 buckets, EC2 instances, or other AWS services that the policy is intended to manage. By clearly outlining these elements, policies provide a structured and detailed framework for managing access and ensuring security within AWS environments.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
]
}
]
}