llm-wiki/raw/official-docs/aws-iam-google-iam-permission-naming-convention.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created, last_reviewed

title	source_type	url	archive_url	related_branches	related_projects	tags	created	last_reviewed
Permission Naming Convention — AWS IAM (service:Action) and Google Cloud IAM (service.resource.verb)	official-doc	https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html		feature-authentication-authorization-contract	ca-skeleton	authorization permission-naming aws-iam google-iam resource-action naming-convention official-doc	2026-06-08	2026-06-08

Permission Naming Convention — AWS IAM (service:Action) and Google Cloud IAM (service.resource.verb)

Layer: raw/official-docs/ — AWS IAM Action element 공식 문서 + Google Cloud IAM permissions 공식 문서의 verbatim 발췌. feature-authentication-authorization-contract 의 permission naming convention axis (resource:action style) 결정의 비교 근거. 두 업계 표준의 naming format 을 grounding 하여 worklog:close 형식의 선택 근거 제공.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-authentication-authorization-contract	resource:action (worklog:close) permission naming convention 채택 결정 — AWS IAM service:Action / Google IAM service.resource.verb 대비 trade-off

출처 / Source

AWS IAM:

• 원본 URL: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html
• 저자 / 조직: Amazon Web Services (AWS Documentation)
• 발행일: rolling docs
• 마지막 확인일: 2026-06-08

Google Cloud IAM:

• 원본 URL: https://docs.cloud.google.com/iam/docs/roles-overview
• 저자 / 조직: Google Cloud (Google LLC)
• 발행일: rolling docs
• 마지막 확인일: 2026-06-08

왜 저장했는지 / Why archived

application-level permission naming (resource:action vs service:action vs service.resource.verb) 의 결정을 업계 표준 두 가지로 grounding. AWS IAM 의 service:Action colon-separated format 과 Google IAM 의 service.resource.verb dot-separated format 은 각각 서로 다른 separator 와 granularity 를 사용하므로, 내부 application permission naming 시 어떤 format 을 참조할지 결정 근거가 됨.

핵심 인용 / Key quotes (verbatim)

AWS IAM Action Element

[§AWS IAM Action — format] "You specify a value using a service namespace as an action prefix (iam, ec2, sqs, sns, s3, etc.) followed by the name of the action to allow or deny. The name must match an action that is supported by the service. The prefix and the action name are case insensitive. For example, iam:ListAccessKeys is the same as IAM:listaccesskeys."

[§AWS IAM Action — examples] "Amazon SQS action: sqs:SendMessage" "Amazon EC2 action: ec2:StartInstances" "IAM action: iam:ChangePassword" "Amazon S3 action: s3:GetObject"

[§AWS IAM Action — wildcard] "You can use multi-character match wildcards () and single-character match wildcards (?) to give access to all the actions the specific AWS product offers. For example, the following Action element applies to all S3 actions: s3:"

Google Cloud IAM Permissions

[§Google IAM — permission format] "Permissions have the following format: SERVICE.RESOURCE.VERB"

[§Google IAM — examples] "the compute.instances.list permission allows a user to list the Compute Engine instances they own, and compute.instances.stop allows a user to stop a VM."

[§Google IAM — API correspondence] "to call the Pub/Sub API's projects.topics.publish method, you need the pubsub.topics.publish permission."

[§Google IAM — role-permission relationship] "When you grant a role to a principal, the principal gets all of the permissions in the role."

[§Google IAM — REST correspondence] "Permissions usually, but not always, correspond 1:1 with REST methods. That is, each Google Cloud service has an associated permission for each REST method that it has. To call a method, the caller needs the associated permission."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
IAM-NAMING-C1	AWS IAM permission format 은 service:Action — colon(:) separator, service namespace 가 prefix, action 이 suffix. case-insensitive	[§AWS IAM Action] "You specify a value using a service namespace as an action prefix...For example, iam:ListAccessKeys"	official-vendor-doc	cloud-level multi-service permission 관리에서 service 간 namespace 분리가 필요한 경우	application-level internal permission 에 동일 format 을 적용해야 한다는 것은 아님 — AWS IAM 은 multi-service cloud scope
IAM-NAMING-C2	Google Cloud IAM permission format 은 service.resource.verb — dot(.) separator, 3-segment (service, resource, verb). REST method 와 1:1 대응	[§Google IAM] "Permissions have the following format: SERVICE.RESOURCE.VERB" + "compute.instances.list" + "Permissions usually, but not always, correspond 1:1 with REST methods."	official-vendor-doc	REST API 와 permission 을 1:1 매핑하는 설계에서 참조	application-internal permission 에 . separator 를 써야 한다는 것은 아님
IAM-NAMING-C3	AWS IAM 에서는 role 이 permission 의 container — role 에 IAM policy 를 attach 하면 policy 의 Action 들이 role 을 통해 부여됨	[§Google IAM] "When you grant a role to a principal, the principal gets all of the permissions in the role." (Google — AWS 도 동일 패턴)	official-vendor-doc	role → permission bundle 패턴의 industry-wide grounding	application-level RBAC 에서 반드시 이 방식을 따라야 한다는 것은 아님
IAM-NAMING-C4	AWS IAM 에서 wildcard 는 s3:* (service-level 전체) 또는 iam:*AccessKey* (action prefix/suffix 패턴) — segment-level wildcard 지원	[§AWS IAM Action] "s3:*" + "iam:AccessKey" examples	official-vendor-doc	permission wildcard 정책 설계 시 참조	application-internal permission 에서 wildcard 가 필요하다는 것은 아님
IAM-NAMING-C5	Google IAM 은 3-segment (service.resource.verb) 로 multi-level resource 계층을 표현. REST method 대응으로 pubsub.topics.publish	[§Google IAM] "to call the Pub/Sub API's projects.topics.publish method, you need the pubsub.topics.publish permission."	official-vendor-doc	multi-service 또는 복잡한 resource hierarchy 환경에서 3-segment 가 필요한 경우	단일 application 내부 permission 에 3-segment 가 필요하다는 것은 아님

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • IAM-NAMING-C1: AWS IAM 은 service:Action colon-separated format
  • IAM-NAMING-C2: Google IAM 은 service.resource.verb dot-separated format
  • IAM-NAMING-C3: 두 시스템 모두 role → permission bundle 패턴 사용
• 이 자료가 증명하지 않는 것:
  • application-internal permission 에 반드시 AWS/Google 형식을 따라야 한다는 것
  • worklog:close 형식이 최선이라는 것 — 이 자료는 industry format 의 reference 를 제공할 뿐
  • OAuth2 scope 와 internal permission 의 차이 — Curity scope best practices 등 별도 자료 위임
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • resource:action (2-segment, colon) 형식이 AWS IAM service:Action 에서 service 를 resource 로 대체한 형태로 이 시스템의 단일 서비스 스코프에 적합한지
  • Google IAM 의 3-segment 가 이 프로젝트 (단일 서비스, sample-portfolio domain) 에 과도한지

메모 / Notes

• 핵심 차이: AWS (service:Action) 는 2-segment colon, Google (service.resource.verb) 는 3-segment dot
• application-level 적용: 단일 서비스 내부 permission 에는 resource:action (2-segment, colon) 이 더 단순하고 AWS IAM 패턴과 구조적으로 유사
• separator 선택: colon (:) 은 AWS IAM 관행, dot (.) 은 Google IAM + OAuth2 scope 일부 관행. URL-safe 고려 시 colon 이 일부 context 에서 encoding 필요할 수 있음 — 내부 permission 에서는 일반적으로 문제없음
• Curity OAuth2 scope best practices (별도 참조): scope 는 entry-point 수준, fine-grained authorization 은 claim/permission 으로 분리 권장 — 이 자료와 함께 검토 필요

Related / 관련

• raw/official-docs/spring-security-authorization-architecture — enforcement mechanism
• raw/official-docs/owasp-authz-permission-model-abac-rbac — permission model 정당화
• raw/branch-notes/feature-authentication-authorization-contract