Atlantis Security
기본 정보
애틀란티스는 기본적으로 귀하의 git 서버에서 풀 리퀘스트로 테라폼을 실행하는 데 도움을 줍니다.
로컬 랩
https://github.com/runatlantis/atlantis/releases의 애틀란티스 릴리스 페이지로 이동하여 적합한 것을 다운로드합니다.
Github 사용자의 repo 액세스를 위한 개인 토큰을 생성합니다.
./atlantis testdrive
를 실행하면 애플리케이션과 대화할 수 있는 데모 레포가 생성됩니다.127.0.0.1:4141에서 웹 페이지에 액세스할 수 있습니다.
애틀란티스 액세스
Git 서버 자격 증명
애틀란티스는 Github, Gitlab, Bitbucket 및 Azure DevOps와 같은 여러 git 호스트를 지원합니다. 그러나 이러한 플랫폼의 리포지토리에 액세스하고 작업을 수행하려면 일부 특권 액세스 권한이 부여되어야 합니다(쓰기 권한 이상). 문서는 특히 애틀란티스를 위해 이러한 플랫폼에 사용자를 생성하도록 권장하지만 일부 사람들은 개인 계정을 사용할 수 있습니다.
공격자의 관점에서 애틀란티스 계정은 매우 흥미로운 대상이 될 것입니다.
웹훅
애틀란티스는 선택적으로 웹훅 비밀을 사용하여 Git 호스트로부터 받은 웹훅이 정당한지 확인합니다.
이를 확인하는 한 가지 방법은 요청을 Git 호스트의 IP에서만 허용하도록하는 것이지만 더 쉬운 방법은 웹훅 비밀을 사용하는 것입니다.
개인 github 또는 bitbucket 서버를 사용하지 않는 한 웹훅 엔드포인트를 인터넷에 노출해야 합니다.
애틀란티스는 웹훅을 노출하여 git 서버가 정보를 보낼 수 있도록 합니다. 공격자의 관점에서는 메시지를 보낼 수 있는지 알아보는 것이 흥미로울 것입니다.
제공자 자격 증명
애틀란티스는 terraform plan
및 apply
명령을 단순히 실행하여 서버 애틀란티스가 호스팅된에서 Terraform을 실행합니다. 로컬에서 Terraform을 실행할 때와 마찬가지로 Atlantis는 특정 제공자에 대한 자격 증명이 필요합니다.
특정 제공자에 대한 자격 증명을 애틀란티스에 제공하는 방법은 다음과 같습니다:
애틀란티스 헬름 차트 및 AWS Fargate 모듈에는 제공자 자격 증명을 위한 고유한 메커니즘이 있습니다. 해당 문서를 참조하세요.
클라우드에서 애틀란티스를 실행하는 경우 많은 클라우드에서 클라우드 API 액세스를 제공하는 방법이 있습니다. 예:
AWS EC2 역할 ("EC2 Role" 검색)
많은 사용자가 Atlantis가 실행되는 위치에서 환경 변수를 설정합니다. 예:
AWS_ACCESS_KEY
다른 사용자는 Atlantis가 실행되는 위치에 필요한 구성 파일을 생성합니다. 예:
~/.aws/credentials
HashiCorp Vault Provider를 사용하여 제공자 자격 증명을 얻습니다.
애틀란티스가 실행되는 컨테이너에는 애틀란티스가 Terraform을 통해 관리하는 제공자(AWS, GCP, Github...)에 대한 특권 자격 증명이 포함되어 있을 가능성이 매우 높습니다.
웹 페이지
기본적으로 애틀란티스는 로컬호스트의 포트 4141에서 웹 페이지를 실행합니다. 이 페이지는 애틀란티스 apply를 활성화/비활성화하고 리포의 계획 상태를 확인하고 잠금을 해제하는 데 사용됩니다(사용자가 수정할 수 없으므로 그다지 유용하지 않습니다).
인터넷에 노출되어 있지 않을 가능성이 높지만 기본적으로 액세스할 때 자격 증명이 필요하지 않습니다(필요한 경우 atlantis
:atlantis
가 기본입니다).
서버 구성
atlantis server
의 구성은 명령줄 플래그, 환경 변수, 구성 파일 또는 세 가지의 혼합을 통해 지정할 수 있습니다.
Atlantis 서버에서 지원하는 플래그 목록은 여기에서 찾을 수 있습니다
여기에서 구성 옵션을 환경 변수로 변환하는 방법을 찾을 수 있습니다.
값은 다음과 같은 순서로 선택됩니다:
플래그
환경 변수
구성 파일
구성에서 토큰 및 비밀번호와 같은 흥미로운 값이 포함될 수 있음에 유의하십시오.
리포 구성
일부 구성은 리포지토리가 관리되는 방식에 영향을 줍니다. 그러나 각 리포지토리가 다른 설정을 필요로 할 수 있으므로 각 리포지토리를 지정하는 방법이 있습니다. 이는 우선 순위 순서입니다:
리포
/atlantis.yml
파일. 이 파일을 사용하여 애틀란티스가 리포지토리를 처리하는 방법을 지정할 수 있습니다. 그러나 기본적으로 일부 키는 플래그를 사용하지 않으면 여기에서 지정할 수 없습니다.allowed_overrides
또는allow_custom_workflows
와 같은 플래그에 의해 허용되어야 할 가능성이 높습니다.서버 측 구성:
--repo-config
플래그로 전달할 수 있으며 각 리포지토리에 대한 새로운 설정을 구성하는 yaml입니다(정규식 지원).기본 값들
PR Protections
Atlantis는 PR이 **approved
**되기를 원하는지 (브랜치 보호에 설정되지 않았더라도) 및/또는 **mergeable
**한지 (브랜치 보호가 통과되었는지) apply를 실행하기 전에 지정할 수 있습니다. 보안적인 측면에서, 두 옵션을 설정하는 것이 권장됩니다.
allowed_overrides
가 True인 경우, 이러한 설정은 각 프로젝트별로 /atlantis.yml
파일에서 덮어쓸 수 있습니다.
Scripts
리포지토리 구성은 워크플로우가 실행되기 전(pre workflow hooks) 및 후(post workflow hooks)에 실행할 스크립트를 지정할 수 있습니다.
이러한 스크립트를 리포 /atlantis.yml
파일에서 지정하는 옵션이 없습니다.
Workflow
리포지토리 구성(서버 측 구성)에서는 새로운 기본 워크플로우를 지정하거나 새로운 사용자 정의 워크플로우를 생성할 수 있습니다. 또한 생성된 새로운 것들에 액세스할 수 있는 리포지토리를 지정할 수 있습니다. 그런 다음, 각 리포의 atlantis.yaml 파일에서 사용할 워크플로우를 지정할 수 있습니다.
서버 측 구성 플래그 allow_custom_workflows
가 True로 설정된 경우, 각 리포의 atlantis.yaml
파일에서 워크플로우를 지정할 수 있습니다. 또한 **allowed_overrides
**가 사용자가 사용할 워크플로우를 덮어쓸 수 있도록 workflow
도 지정해야 할 수도 있습니다.
이는 기본적으로 해당 리포에 액세스할 수 있는 모든 사용자에게 Atlantis 서버에서 RCE를 제공할 것입니다.
Conftest 정책 확인
Atlantis는 서버 측 conftest 정책을 계획 출력에 대해 실행하는 것을 지원합니다. 이 단계를 사용하는 일반적인 사례는 다음과 같습니다:
모듈 목록 사용 거부
생성 시 리소스의 속성 단언
의도하지 않은 리소스 삭제 감지
보안 위험 방지 (예: 안전한 포트를 공개)
문서에서 구성 방법을 확인할 수 있습니다.
Atlantis 명령어
문서에서 Atlantis를 실행하는 데 사용할 수 있는 옵션을 찾을 수 있습니다.
공격
만약 공격 중에 다음 오류를 발견한다면: Error: Error acquiring the state lock
다음을 실행하여 해결할 수 있습니다:
Atlantis plan RCE - 새 PR에서 구성 수정
만약 귀하가 저장소에 쓰기 액세스 권한이 있다면 해당 저장소에 새 브랜치를 생성하고 PR을 생성할 수 있습니다. atlantis plan
을 실행할 수 있다면(또는 자동으로 실행되는 경우) Atlantis 서버 내에서 RCE를 실행할 수 있습니다.
이를 수행하는 방법은 Atlantis가 외부 데이터 소스를 로드하도록 하는 것입니다. main.tf
파일에 다음과 같은 payload를 넣으면 됩니다:
은밀한 공격
이 공격을 더 은밀하게 수행할 수 있습니다. 다음 제안을 따르세요:
테라폼 파일에 직접 rev 쉘을 추가하는 대신, rev 쉘을 포함하는 외부 리소스를 로드할 수 있습니다:
rev shell 코드는 https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules에서 찾을 수 있습니다.
외부 자원에서 ref 기능을 사용하여 리포지토리 내의 브랜치에 terraform rev shell 코드를 숨기세요, 다음과 같이:
git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Atlantis를 트리거하기 위해 마스터로 PR을 생성하는 대신, 2개의 브랜치(test1 및 test2)를 생성하고 한 브랜치에서 다른 브랜치로 PR을 생성합니다. 공격을 완료하면 PR과 브랜치를 제거하십시오.
Atlantis plan Secrets Dump
atlantis plan
(terraform plan
)을 실행하여 terraform에서 사용된 비밀을 덤프할 수 있습니다. 이를 위해 terraform 파일에 다음과 같은 내용을 넣으십시오:
Atlantis apply RCE - 새 PR에서 구성 수정
만약 귀하가 저장소에 쓰기 액세스 권한이 있다면 해당 저장소에 새 브랜치를 생성하고 PR을 생성할 수 있습니다. atlantis apply
를 실행할 수 있다면 Atlantis 서버 내에서 RCE를 실행할 수 있습니다.
그러나 일반적으로 일부 보호 기능을 우회해야 할 수 있습니다:
병합 가능(Mergeable): Atlantis에서 이 보호 기능이 설정된 경우, PR이 병합 가능한 경우에만
atlantis apply
를 실행할 수 있습니다 (즉, 브랜치 보호를 우회해야 함).브랜치 보호 우회를 확인하세요.
승인(Approved): Atlantis에서 이 보호 기능이 설정된 경우, 다른 사용자가 PR을 승인해야만
atlantis apply
를 실행할 수 있습니다.
악성 Terraform 파일에서 terraform apply
를 실행하면서 local-exec을 사용합니다.
다음과 같은 페이로드가 main.tf
파일에 포함되도록만 하면 됩니다:
이전 기술의 제안을 따라 이 공격을 보다 은밀하게 수행하십시오.
Terraform Param Injection
atlantis plan
또는 atlantis apply
를 실행할 때 terraform이 필요로 하는 상황에서, atlantis에서 다음과 같이 주석을 달아 terraform에 명령을 전달할 수 있습니다:
사용자 정의 워크플로우
atlantis.yaml
파일에 지정된 악성 사용자 정의 빌드 명령어를 실행합니다. Atlantis는 master
가 아닌 풀 리퀘스트 브랜치의 atlantis.yaml
파일을 사용합니다.
이 가능성은 이전 섹션에서 언급되었습니다:
만약 서버 측 구성 플래그 allow_custom_workflows
가 True로 설정되어 있다면, 각 레포지토리의 atlantis.yaml
파일에 워크플로우를 지정할 수 있습니다. 또한 **allowed_overrides
**가 **workflow
**도 지정하여 사용할 워크플로우를 오버라이드해야 할 수도 있습니다.
이는 기본적으로 해당 레포지토리에 액세스할 수 있는 모든 사용자에게 Atlantis 서버에서 RCE를 제공할 것입니다.
우회 plan/apply 보호
만약 서버 측 구성 플래그 allowed_overrides
에 apply_requirements
가 구성되어 있다면, 해당 리포지토리가 계획/적용 보호를 우회하여 수정할 수 있습니다.
PR Hijacking
만약 누군가가 당신의 유효한 풀 리퀘스트에 atlantis plan/apply
댓글을 남기면, terraform이 원하지 않을 때 실행되게 됩니다.
게다가, 브랜치 보호에 **새로운 커밋이 푸시될 때마다 모든 PR을 재평가하도록 구성하지 않은 경우, 누군가가 terraform 구성에서 악성 구성(이전 시나리오 확인)을 작성하고 atlantis plan/apply
를 실행하여 RCE를 얻을 수 있습니다.
이것은 Github 브랜치 보호 설정입니다:
Webhook Secret
만약 웹훅 시크릿을 탈취하거나 사용 중인 웹훅 시크릿이 없는 경우, Atlantis 웹훅을 호출하고 직접 atlantis 명령을 실행할 수 있습니다.
Bitbucket
Bitbucket Cloud는 웹훅 시크릿을 지원하지 않습니다. 이는 공격자가 Bitbucket에서 요청을 위장할 수 있게 합니다. 오직 Bitbucket IP만 허용하도록 해야 합니다.
이는 공격자가 Bitbucket에서 온 것처럼 보이는 Atlantis에 가짜 요청을 만들 수 있게 합니다.
만약
--repo-allowlist
를 지정하고 있다면, 그들은 해당 리포에 관한 가짜 요청만 만들 수 있기 때문에 가장 큰 피해는 자신의 리포에서 plan/apply를 실행하는 것입니다.이를 방지하기 위해 Bitbucket의 IP 주소를 허용목록에 추가하세요 (Outbound IPv4 주소 참조).
사후 공격
서버에 액세스를 얻거나 적어도 LFI를 얻었다면 읽어볼만한 흥미로운 것들이 있습니다:
/home/atlantis/.git-credentials
VCS 액세스 자격 증명 포함/atlantis-data/atlantis.db
더 많은 정보가 포함된 VCS 액세스 자격 증명 포함/atlantis-data/repos/<org_name>
/
<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate
Terraform 상태 파일예: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ
환경 변수/proc/[2-20]/cmdline
atlantis server
의 Cmd 라인 (민감한 데이터 포함 가능)
완화 방법
공개 리포지토리에서 사용하지 마세요
누구나 공개 풀 리퀘스트에 댓글을 남길 수 있기 때문에 모든 보안 완화 조치가 가능하더라도, 보안 설정을 제대로 구성하지 않은 상태에서 공개 리포지토리에서 Atlantis를 실행하는 것은 여전히 위험합니다.
--allow-fork-prs
사용하지 마세요
--allow-fork-prs
사용하지 마세요권장되지 않는 공개 리포지토리에서 실행 중이라면 --allow-fork-prs
를 설정하지 마세요 (기본값은 false) - 누구나 자신의 포크에서 당신의 리포지토리로 풀 리퀘스트를 열 수 있기 때문입니다.
--repo-allowlist
--repo-allowlist
Atlantis는 --repo-allowlist
플래그를 통해 웹훅을 수락할 리포지토리의 목록을 지정해야 합니다. 예를 들어:
특정 리포지토리:
--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
전체 조직:
--repo-allowlist=github.com/runatlantis/*
GitHub Enterprise 설치의 모든 리포지토리:
--repo-allowlist=github.yourcompany.com/*
모든 리포지토리:
--repo-allowlist=*
. 웹훅 시크릿을 설정하지 않은 경우 보안 네트워크에서 유용하지만 위험합니다.
이 플래그는 Atlantis 설치가 제어하지 않는 리포지토리와 함께 사용되지 않도록 합니다. 자세한 내용은 atlantis server --help
를 참조하세요.
Terraform Planning 보호
악성 Terraform 코드를 제출하는 공격자가 당신의 위협 모델에 있다면, terraform apply
승인만으로 충분하지 않음을 인식해야 합니다. external
데이터 소스를 사용하거나 악의적인 프로바이더를 지정하여 terraform plan
에서 악성 코드를 실행할 수 있습니다. 이 코드는 그런 다음 귀하의 자격 증명을 유출할 수 있습니다.
이를 방지하기 위해 다음을 수행할 수 있습니다:
Atlantis 이미지에 프로바이더를 포함하고 프로덕션에서 egress를 거부합니다.
내부적으로 프로바이더 레지스트리 프로토콜을 구현하고 공개 egress를 거부하여 레지스트리에 쓰기 액세스를 제어합니다.
서버 측 리포지토리 구성의
plan
단계를 수정하여 금지된 프로바이더나 데이터 소스 사용을 검증하거나 허용되지 않은 사용자의 PR을 거부할 수 있습니다. 여기에 추가 검증을 추가할 수도 있습니다. 예를 들어plan
을 계속하기 전에 PR에 "좋아요"를 요구하는 것 등. Conftest를 여기에 사용할 수 있습니다.
웹훅 시크릿
Atlantis는 $ATLANTIS_GH_WEBHOOK_SECRET
/$ATLANTIS_GITLAB_WEBHOOK_SECRET
환경 변수를 통해 설정된 웹훅 시크릿으로 실행되어야 합니다. --repo-allowlist
플래그가 설정되어 있더라도 웹훅 시크릿이 없으면, 공격자가 허용 목록에 있는 리포지토리로 위장하여 Atlantis에 요청을 보낼 수 있습니다. 웹훅 시크릿은 웹훅 요청이 실제로 귀하의 VCS 제공업체 (GitHub 또는 GitLab)에서 오는지 확인합니다.
Azure DevOps를 사용하는 경우, 웹훅 시크릿 대신 기본 사용자 이름과 암호를 추가하세요.
Azure DevOps 기본 인증
Azure DevOps는 모든 웹훅 이벤트에서 기본 인증 헤더를 보낼 수 있습니다. 웹훅 위치에 HTTPS URL을 사용해야 합니다.
SSL/HTTPS
웹훅 시크릿을 사용하고 있지만 트래픽이 HTTP를 통해 전송되는 경우 웹훅 시크릿이 탈취될 수 있습니다. --ssl-cert-file
및 --ssl-key-file
플래그를 사용하여 SSL/HTTPS를 활성화하세요.
Atlantis 웹 서버에서 인증 활성화
웹 서비스에서 인증을 활성화하는 것이 매우 권장됩니다. --web-basic-auth=true
를 사용하여 BasicAuth를 활성화하고 --web-username=yourUsername
및 --web-password=yourPassword
플래그를 사용하여 사용자 이름과 암호를 설정하세요.
이를 환경 변수로도 전달할 수 있습니다. ATLANTIS_WEB_BASIC_AUTH=true
, ATLANTIS_WEB_USERNAME=yourUsername
, ATLANTIS_WEB_PASSWORD=yourPassword
.
참고 자료
Last updated