IAM 역할과 정책

Welcome to the lesson on IAM Roles and Policies! In AWS, security is paramount. Managing access securely is crucial for any backend application.

IAM Roles provide a powerful way to delegate permissions without sharing long-term credentials. They are a core concept for building secure, scalable AWS applications.

Before diving deep, let's briefly recap IAM identities:

• IAM Users: Typically represent a person or service with long-term credentials.
• IAM Groups: Collections of IAM users, making it easier to manage permissions for multiple users.
• IAM Roles: Identities that you can assume to gain temporary permissions. They are distinct because they don't have standard long-term credentials associated with them.

Our focus today is on these powerful IAM Roles.

An IAM role is an AWS identity with permission policies that determine what the identity can do in AWS. It's designed to be assumable by:

• An AWS service (e.g., an EC2 instance, Lambda function).
• An AWS account (allowing cross-account access).
• An external identity provider (like your corporate directory).

Roles allow temporary, fine-grained access, enhancing security by avoiding static credentials.

Every IAM role has a Trust Policy (also called an 'assume role policy'). This policy defines who or what is allowed to assume the role.

For example, if you want an EC2 instance to assume a role, its trust policy would specify the EC2 service as the trusted entity. This is the first layer of security for roles.

Once a role is assumed, its actions are governed by Permissions Policies. These policies define what actions the role is allowed (or denied) to perform on which AWS resources.

These are identity-based policies, written in JSON format, and attached directly to the role.

IAM policies are structured JSON documents. Here's a common structure:

• Version: The policy language version.
• Statement: An array of individual permission statements.
• Effect: Whether the statement Allows or Denys access.
• Action: The specific AWS API calls allowed/denied (e.g., s3:GetObject).
• Resource: The AWS resources on which the action applies (e.g., arn:aws:s3:::my-bucket/*).

Permissions policies can be categorized:

• AWS Managed Policies: Created and managed by AWS (e.g., AmazonS3ReadOnlyAccess). Easy to use but broad.
• Customer Managed Policies: Created and managed by you. Offer fine-grained control and reusability.
• Inline Policies: Embedded directly into a single IAM identity (user, group, or role). Not reusable, deleted with the identity.

For roles, customer managed policies are often preferred for their balance of control and reusability.

Imagine you have an EC2 instance that needs to read files from an S3 bucket.

Instead of storing AWS credentials on the EC2 instance (a security risk!), you'd create an IAM role with permissions to read from S3. The EC2 service would be listed in the role's trust policy.

When the EC2 instance launches, you attach this role. The instance can then assume the role and gain temporary credentials to access S3 securely.

To maximize security and efficiency with IAM roles:

• Principle of Least Privilege: Grant only the permissions absolutely necessary for a role to perform its task.
• Regular Auditing: Periodically review your roles and their attached policies to ensure they still meet current needs.
• Use Roles Over Static Credentials: Always prefer roles for AWS services or cross-account access instead of embedding access keys.
• Meaningful Naming: Use clear, descriptive names for your roles and policies.

Great job! In this lesson, we explored IAM Roles and Policies. You learned:

• IAM roles enable secure, temporary access for services and accounts.
• Trust Policies define who can assume a role.
• Permissions Policies define what actions an assumed role can perform.
• Policies are JSON documents specifying effects, actions, and resources.
• Best practices include least privilege and auditing.

Mastering IAM roles is a key step towards building robust and secure applications on AWS. Keep practicing!