작업 흐름 실행 권한

워크플로 실행 권한이 생각보다 중요한 이유

CI/CD 파이프라인, 데이터 처리 작업, 인프라 프로비저닝 등 자동화된 워크플로는 허용되는 작업을 결정하는 권한에 따라 달라집니다. 그러나 권한은 나중에 고려되는 경우가 많습니다. 즉, 한 번 설정하면 잊어버리게 됩니다. 이는 파이프라인이 중간에 실패하거나 더 나쁜 경우 악의적인 행위자가 과도한 권한을 가진 토큰을 악용할 때까지 작동합니다.

일반적인 시나리오를 생각해 보십시오. 개발자가 코드를 리포지토리에 푸시하고 Docker 이미지를 빌드하고 이를 레지스트리에 푸시하는 CI 파이프라인을 트리거한 다음 스테이징 서버에 배포합니다. 각 단계에는 저장소에 대한 읽기 액세스 권한, 레지스트리에 대한 쓰기 액세스 권한, 스테이징 서버에 대한 SSH 액세스 권한 등 다양한 권한이 필요합니다. 이러한 권한 중 하나라도 잘못 구성되면 파이프라인이 자동으로 실패하거나 비밀을 노출합니다.

워크플로 실행 권한은 단순히 "워크플로를 실행할 수 있는 사람"에 관한 것이 아닙니다. 여기에는 다음이 포함됩니다.

실행을 시작할 수 있는 ID(사용자, 서비스 계정, 시스템)는 무엇입니까?
실행 중에 워크플로가 액세스할 수 있는 리소스입니다.
워크플로가 해당 리소스에 대해 수행할 수 있는 작업은 무엇입니까?

문제는 이러한 권한이 소스 제어, 아티팩트 저장소, 컴퓨팅 환경, 비밀 관리 등 여러 시스템에 걸쳐 계단식으로 적용된다는 것입니다. 잘못 구성된 단일 토큰으로 인해 전체 배포가 중지될 수 있습니다.

구체적인 시나리오: 금요일에 중단된 스테이징 배포

실제 예를 들어 보겠습니다. Sarah는 핀테크 스타트업의 DevOps 엔지니어입니다. 그녀는 다음과 같은 GitHub Actions 워크플로를 설정합니다.

main에 푸시하면 Node.js 앱을 빌드합니다.
단위 테스트를 실행합니다.
Docker 이미지를 AWS ECR에 푸시합니다.
kubectl을 통해 Kubernetes 스테이징 클러스터에 배포합니다.

워크플로를 실행하기 위해 그녀는 ECR에 푸시하고 Kubernetes 배포를 업데이트할 권한이 있는 IAM 사용자를 통해 GitHub Actions 비밀 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY을 생성합니다.

모든 것이 몇 주 동안 작동합니다. 그러던 어느 금요일, 팀원이 사소한 변경 사항을 푸시하고 워크플로가 3단계에서 "AccessDenied" 오류와 함께 실패합니다. Sarah는 IAM 사용자를 확인합니다. 변경된 사항은 없습니다. AWS 비밀은 여전히 존재합니다. 무슨 일이에요?

문제: IAM 사용자의 키는 정기적인 규정 준수 조사의 일환으로 보안 팀에 의해 순환되었지만 GitHub 비밀은 업데이트되지 않았습니다. 워크플로에서 잘못된 키를 사용하려고 했으나 실패했습니다.

이는 전형적인 실패 모드입니다. 즉, 외부 변경으로 인해 발생하는 권한 드리프트입니다. 워크플로 자체는 변경되지 않았지만 기본 자격 증명은 변경되었습니다. 아무도 회전을 알아차리지 못했기 때문에 파이프라인은 몇 시간 동안 중단되었습니다.

커피잔 옆에 '워크플로 권한 마이그레이션 단계'라는 제목의 체크리스트 문서가 열려 있는 노트북을 들고 책상에 앉아 있는 개발자

워크플로 실행 권한이 실패하는 이유

자격 증명 드리프트 외에도 다른 일반적인 실패 모드는 다음과 같습니다.

지나치게 광범위한 권한: 무제한 액세스 권한을 부여하는 관리자 수준 서비스 계정을 사용합니다. 워크플로가 손상되면 폭발 반경이 늘어납니다.
범위 지정 부족: 저장소 하나만 필요한 경우 모든 저장소에 대한 쓰기 액세스 권한을 부여합니다.
하드코딩된 비밀: 로그에 노출되는 코드 또는 워크플로 파일에 API 키를 삽입합니다.
OIDC 또는 토큰 교환 누락: 동적으로 발행될 수 있는 단기 토큰 대신 장기 자격 증명을 사용합니다.

우리 시나리오에서는 작업당 단기 토큰을 발행하고 정적 키가 필요하지 않은 GitHub Actions와 함께 AWS의 OIDC 공급자를 사용하여 수정했을 수 있습니다. 그러나 대상 플랫폼이 OIDC를 지원하지 않는 경우 항상 가능한 것은 아닙니다.

커피잔 옆에 '워크플로 권한 마이그레이션 단계'라는 제목의 체크리스트 문서가 열려 있는 노트북을 들고 책상에 앉아 있는 개발자

실용적인 경로: 최소 권한 워크플로 권한 구현

금요일 밤의 정전을 방지하려면 다음 단계를 따르세요.

모든 리소스 액세스 매핑: 각 워크플로 단계에 대해 정확한 API 호출 및 리소스를 나열합니다. 예를 들어 repo의 ecr:PutImage, 클러스터의 eks:UpdateClusterConfig 및 저장소에 대한 읽기 액세스 권한이 있습니다.
가능한 경우 OIDC를 사용하세요: GitHub Actions, GitLab CI 등이 OIDC를 지원합니다. 이는 워크플로 ID를 저장소 및 분기에 연결하여 작업 범위가 지정된 단기 토큰을 발급합니다.
범위 지정 서비스 계정: OIDC를 사용할 수 없는 경우 워크플로 또는 환경별로 전용 서비스 계정을 만듭니다. 단일 관리자 계정을 재사용하지 마십시오.
자격 증명 순환 자동화: 키를 자동으로 순환하고 API를 통해 워크플로 공급자에 업데이트를 푸시하는 비밀 관리자(AWS Secrets Manager, HashiCorp Vault)를 사용합니다.
권한 파이프라인 테스트: 각 단계에서 필요한 리소스에 액세스할 수 있는지 확인하는 통합 테스트를 작성합니다. 이는 배포 전에 드리프트를 포착합니다.

Sarah의 경우 OIDC로 전환하면 하드코딩된 AWS 키가 제거되었을 것입니다. OIDC 공급자 자체가 다운된 경우에만 워크플로가 실패했으며(드문 경우) 자격 증명은 매시간 자동으로 교체되었습니다.

권한이 침해되면 어떻게 되나요? 결과와 회복

워크플로 실행 권한이 실패하면 즉각적인 증상은 파이프라인 오류입니다. 그러나 실제 비용은 시간입니다. 개발자는 수정을 기다리고, 배포 기간은 닫히고, 이해관계자는 신뢰를 잃습니다.

복구 계획:

Have a rollback strategy: revert the workflow to a known-good version or switch to manual deployment.
대체 ID 사용: 기본 서비스 계정에 장애가 발생하면 경고를 트리거하고 동일한 범위의 보조 계정으로 대체합니다(긴급 사용에만 해당).
Run a post-mortem: update permissions documentation, rotate credentials, and add monitoring for permission expiration.

Alternative Approaches for Complex Environments

If your organization has multiple teams or complex compliance requirements, consider:

워크플로 수준 RBAC: 일부 워크플로 엔진(예: Apache Airflow)은 워크플로를 트리거하거나 수정할 수 있는 사람을 제한하는 역할 기반 액세스 제어를 제공합니다.
Policy-as-code: Tools like OPA (Open Policy Agent) can enforce permissions at runtime, blocking unauthorized actions dynamically.
Separate workflow environments: Use different credentials for dev, staging, and production. Never allow a workflow running from main to access production unless it passed all checks.

각 접근 방식에는 장단점이 있습니다. RBAC는 구성 오버헤드를 추가합니다. 코드형 정책을 사용하려면 새로운 DSL을 배워야 합니다. Separate environments mean more secrets to manage. Choose based on your team's size and compliance needs.

최종 생각

Workflow execution permissions are a linchpin of reliable automation. They're not just about security—they directly affect uptime. A well-designed permissions model reduces failures, simplifies debugging, and shortens recovery time.

CI/CD 파이프라인, 데이터 워크플로 또는 자동화된 시스템을 구축하는 경우 각 실행 컨텍스트에 대한 권한을 설계하는 데 미리 시간을 투자하세요. Use OIDC or short-lived tokens, automate rotation, and test regularly. 금요일 저녁은 감사할 것입니다.