"개발자에게 S3 읽기 권한을 주려면 IAM으로 해야 하나요, RBAC로 해야 하나요?" — 이 질문 자체가 두 개념의 관계를 혼동하고 있다는 신호입니다. IAM은 접근 제어 시스템 전체를 가리키고, RBAC는 그 안에서 권한을 부여하는 방식 중 하나입니다.핵심 요약IAM(Identity and Access Management)은 "누가, 무엇에, 어떤 작업을 할 수 있는가"를 관리하는 시스템 전체를 의미합니다.RBAC(Role-Based Access Control)는 역할(Role)을 기준으로 권한을 묶어서 부여하는 접근 제어 모델입니다.AWS는 IAM 안에서 Policy 기반(ABAC/PBAC)과 Role 기반(RBAC)을 혼합하여 사용합니다.Azure는 IAM 계층 안에서 RBAC를 명시적으로 분리..

GitHub Actions에서 AWS에 배포할 때 Access Key를 Repository Secret에 저장하고 있다면, 그 Key는 누가 마지막으로 교체했는지, 어떤 권한이 붙어 있는지 확인해볼 필요가 있습니다. 팀원이 퇴사해도 Key는 남아 있고, 유출되면 교체할 때까지 무제한으로 사용됩니다. OIDC(OpenID Connect)는 이 문제를 구조적으로 해결합니다. 장기 자격 증명을 저장하지 않고, 실행 시점에 단기 토큰을 발급받아 사용하는 방식입니다.핵심 요약OIDC 기반 인증은 장기 자격 증명(Access Key, Service Account Key) 자체를 제거하여 유출 위험을 구조적으로 줄입니다.GitHub Actions, EKS Pod, GKE Pod 모두 동일한 원리로 동작합니다: 워크로..

Lambda에서 S3 객체를 읽으려는데 AccessDenied가 반환됩니다. IAM Role에 s3:GetObject를 붙였는데 왜 안 될까요? S3 AccessDenied는 권한 평가 계층이 여러 겹이라 원인을 특정하기 어렵습니다. 이 글에서는 원인별 진단 흐름과 해결 방법을 정리합니다.핵심 요약원인증상확인 방법IAM Policy에 Action/Resource 누락모든 S3 요청에서 403IAM Policy Simulator 또는 aws iam simulate-principal-policyBucket Policy에 명시적 Deny특정 조건에서만 403Bucket Policy의 Deny Statement 확인Block Public Access 활성화Public ACL/Policy 설정 시 403S3 콘솔..

GCP IAM은 "누가(Principal) 무엇을(Role) 어디에(Resource) 할 수 있는가"를 allow policy로 묶어 권한을 부여합니다. 이 세 가지를 분리해서 이해하면 권한 설계가 단순해집니다.핵심 요약GCP IAM의 권한 부여는 Principal에게 Resource에 대한 Role을 grant하는 한 문장으로 요약됩니다.Principal은 권한을 받는 주체(사용자, 서비스 계정, 그룹 등)입니다.Role은 권한(Permission)의 묶음이며, Permission은 service.resource.verb 형식입니다.Allow Policy는 "어떤 Principal에게 어떤 Role을 부여하는가"를 정의한 binding의 모음이고, Resource에 붙습니다.Permission은 Pri..

Azure RBAC는 "누가(Security Principal)", "무엇을(Role Definition)", "어디서(Scope)"라는 세 가지를 묶어 권한을 부여하는 인가(Authorization) 시스템입니다. 이 세 요소의 조합이 Role Assignment이며, RBAC 설계의 출발점입니다.핵심 요약Azure RBAC는 Azure 리소스에 대한 접근을 관리하는 인가(Authorization) 시스템입니다.Role Assignment는 Security Principal(누가), Role Definition(무엇을), Scope(어디서) 세 요소로 구성됩니다.Scope는 Management Group → Subscription → Resource Group → Resource 4계층으로 구성되며, ..

IAM Role은 "누가 이 권한을 사용할 수 있는가"를 정의하고, IAM Policy는 "어떤 작업을 허용하거나 거부하는가"를 정의합니다. 이 두 가지를 분리해서 설계해야 권한 관리가 확장 가능해집니다.핵심 요약IAM Policy는 "무엇을 할 수 있는가"를 JSON으로 정의한 권한 규칙입니다.IAM Role은 "누가 이 권한을 사용할 수 있는가"를 정의한 자격 증명 컨테이너입니다.Policy는 Role에 연결(Attach)되어야 실제로 동작합니다. Policy 단독으로는 아무 효과가 없습니다.Role은 사람이 아닌 서비스(EC2, Lambda 등)에도 권한을 부여할 수 있는 유일한 방법입니다.실무에서는 Policy를 재사용 가능한 단위로 설계하고, Role을 통해 필요한 주체에 조합하여 연결합니다.1..