상담원 워크플로 권한은 어떻게 작동하나요? 실제 링크로 알려드릴게요

권한은 스위치가 아니라 에이전트의 작동 경계입니다.

자동으로 코드를 읽고 쓰고, PR을 제출하고, AWS CLI를 호출할 수 있는 에이전트를 구축한다고 가정해 보겠습니다. "프로덕션에 배포"라고 지시하면 에이전트에 어떤 권한이 필요합니까? 많은 사람들의 첫 번째 반응은 "그냥 관리자 자격 증명을 제공하세요"입니다. 이는 첫 번째 오해입니다.

에이전트 워크플로 권한은 액세스 카드와 같은 이진 "예/아니요" 스위치가 아니라 세분화된 범위 및 제약 조건의 집합입니다. 각 권한은 실제로 두 가지 작업을 수행합니다. 즉, 에이전트가 작동할 수 있는 리소스와 해당 리소스에서 수행할 수 있는 작업을 정의합니다.

실제 연결: 의도에서 실행까지

저는 몇 년 전에 CI/CD 파이프라인을 맡았는데, 여기서 에이전트는 코드 가져오기 → 테스트 실행 → 이미지 빌드 → ECR로 푸시 → ECS 서비스 업데이트를 담당했습니다. 이 프로세스에는 6가지 권한 집합이 포함됩니다.

1. 코드 웨어하우스 읽기 권한(풀코드)
2. 빌드 환경 쓰기 권한(캐시, 로그)
3. 미러웨어 하우스 쓰기 권한(푸시 이미지)
4. 오케스트레이션 서비스 업데이트 권한(트리거 배포)
5. 키 관리 읽기 권한(데이터베이스 비밀번호 획득)
6. 로그 쓰기 권한(기록 실행 결과)

그 당시 저는 문제를 해결하고 싶었고 "개발자 전체 권한" 역할을 에이전트에 바인딩했습니다. 첫 주는 괜찮게 흘러갔다. 세 번째 주에는 실수로 인한 작업으로 인해 에이전트가 사용되지 않은 EBS 볼륨(아직 3일간의 테스트 데이터가 포함된 볼륨)을 삭제했습니다. 수정하는 데 이틀이 걸렸습니다.

그 후에 저는 상담사 워크플로 권한이 '무엇을 할 수 있는지'가 아니라 '잘못할 경우 얼마나 큰 피해를 입을지'에 관한 것이라는 점을 정말 이해하게 되었습니다.

권한 체크리스트: 에이전트를 대상으로 검토합니다.

그 이후로 제가 사용해 온 체크리스트는 다음과 같습니다. 새 에이전트 워크플로를 만들 때마다 하나씩 확인합니다.

• 각 단계에는 해당 작업을 수행하는 데 필요한 최소한의 권한만 있습니까? 예를 들어 테스트 단계에서는 ECR을 수정하기 위한 권한이 필요하지 않습니다.
• 권한 범위가 리소스 ID 또는 태그로 지정됩니까? 예를 들어 env=staging 태그가 있는 리소스만 작동이 허용됩니다.
• 민감한 작업(리소스 삭제, IAM 수정, 키 읽기 및 쓰기)에 대한 추가 확인 메커니즘이 있습니까? 예를 들어 2차 승인 또는 수동 개입 단계가 있습니다.
• 워크플로가 별도의 IAM 역할로 실행됩니까? 여러 에이전트를 동일한 역할에 벼락치기하지 마세요.
• 권한 정책에 버전이 지정되어 있습니까? 모든 변경 사항은 롤백되고 감사될 수 있습니다.
• 실행 시간 초과 및 빈도 제한이 설정되었습니까? 권한 증폭으로 이어지는 무한한 재시도를 피하세요.

가장 들어가기 쉬운 함정

** 함정 1: 상담원의 역할을 사용자에게 바인딩합니다. ** 많은 플랫폼에서는 현재 사용자 자격 증명으로 직접 에이전트를 생성할 수 있습니다. 장점은 빠르지만, 에이전트가 관련 없는 리소스를 삭제하는 권한을 포함해 사용자의 모든 권한을 얻는다는 단점이 있다. 올바른 접근 방식은 각 워크플로에 대한 전용 역할을 만드는 것입니다.

** 함정 2: 교차 계정 권한을 무시합니다. ** 에이전트가 다른 AWS 계정의 S3 버킷에 액세스해야 하는 경우 AssumeRole 권한을 갖기 위해 이 계정의 역할이 필요할 뿐만 아니라 다른 계정이 이 역할을 신뢰해야 합니다. 이 링크는 가장 쉽게 잊어버리기 때문에 런타임 중에 "권한 부족" 오류가 발생합니다.

** 함정 3: Resource 필드에 대한 권한 정책이 너무 느슨합니다. ** 예를 들어 "Resource": "*"는 모든 리소스를 노출합니다. Action이 s3:GetObject로 제한되더라도 버킷 정책에서 허용하면 에이전트는 전체 버킷을 읽을 수 있습니다. 항상 리소스를 특정 버킷 경로나 리소스 ARN으로 제한하는 것이 좋습니다.

실패 시 대처 방법: 다운그레이드 및 탈출 해치

최선을 다해 확인하더라도 권한 오류가 계속 발생할 수 있습니다. 제가 경험한 것은 에이전트가 오전 3시에 ECS 서비스를 업데이트하려고 했을 때 역할 세션 시간 초과로 인해 실패했다는 것입니다. 해결책은 더 큰 권한을 부여하는 것이 아니라 다음을 수행하는 것입니다.

1. 워크플로에 재시도 논리를 추가하고 권한 예외를 포착한 후 작업 대상을 자동으로 낮춥니다(예: "업데이트 서비스"에서 "출력 차이점만"으로 다운그레이드).
2. 디버깅 및 프로덕션 스냅샷에 대한 읽기 전용 권한이 있는 대체 역할을 준비합니다.
3. 이후 이유 감사를 용이하게 하기 위해 별도의 보안 계정에 인증 실패 로그를 기록합니다.

요약

에이전트 워크플로 권한의 핵심은 모든 위험을 예방하는 것이 아니라 위험을 허용 가능한 범위로 제어하는 것입니다. 모든 허가문은 방어선입니다. 다음에 작업 흐름에 단계를 추가할 때 다음과 같이 질문해 볼 수도 있습니다. 이 단계가 악의적으로 사용되면 최대 손실은 얼마입니까? 답변을 통해 더욱 안전한 권한 정책을 작성할 수 있습니다.