3.3 KiB
title, type, source-type, category, tags, date-added, video-source, audio-source, status
| title | type | source-type | category | tags | date-added | video-source | audio-source | status | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CTP Topic 5 - AWS Identity and Access Management (IAM) | cloud-learning | video | DevOps & SRE/02_IAM |
|
2026-04-14 | nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 5 - AWS Identity and Access Management (IAM).mp4 | summarized (Gemini 摘要) |
CTP Topic 5 - AWS Identity and Access Management (IAM)
Source: NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 5 - AWS Identity and Access Management (IAM).mp4
Type: VIDEO | Category: 02_IAM
Status: 🟡 Awaiting Whisper transcription → Summary
摘要
AWS Identity and Access Management (IAM) Explained
This session covers AWS Identity and Access Management (IAM), focusing on users, groups, roles, and policies, and how they relate to accessing AWS via the CLI and federation. The discussion emphasizes accessing landing zone accounts and determining the appropriate method.
Key points include:
- IAM dashboard resources: users, groups, customer managed policies, roles, and identity providers.
- Federated access: Users gain access to accounts via Active Directory (AD) groups, which grant specific roles.
accounts.json: This file, located in the root of every landing zone, contains a list of account numbers.- IAM users are primarily for service accounts; federation is the preferred method for user management.
- User groups are less relevant due to the focus on federated user management.
- Roles are used by services or users and tie together permissions.
- Policies define permissions, specifying what actions are allowed or denied on resources.
- Roles don't enable actions; they tie together who can do something and what they can do.
- Policies can be AWS-managed or customer-managed.
Federated users log in via their organization's AD, which maps to an IAM role. Command-line access via federation requires a tool called PFSSO. We only want to allow the access that is strictly required. Least privilege model: Granting only the necessary permissions is crucial.
Configuring permissions typically involves a service accessing AWS resources, requiring a role and policy. Terraform modules can define IAM roles, including an assumed role policy and inline policy blocks. Policies should be fine-grained, limiting access to only the required resources. Inline policies are tied to a specific role, while managed policies can be reused across multiple roles.
Key takeaways:
- Federation is the primary method for user access.
- Roles and policies are central to managing permissions.
- Least privilege is a guiding principle when defining policies.
- Consider using inline policies for role-specific permissions and managed policies for reusable permissions.
- When defining pterogrant modules, ensure policies are not too wide open.
- VSM requests are required to gain account access through Federation.
- User attributes beyond usernames are supported, including additional STS values and tags.
- Cross-account role assumption is possible, where principles in specified accounts can assume a role.
关键概念
行动项
相关视频
配对视频笔记链接（生成后填入）
最后更新: 2026-04-14