Deadshot은 각 차이점 라인을 알려진 비밀 표현 세트와 일치시켜 PR을 통해 비밀의 도입을 찾는 풀 요청 스캐너입니다.
서비스는 다음을 담당합니다.
서비스는 다음을 수행하지 않습니다:
Deadshot은 Github 앱이 설치된 저장소의 메인 브랜치에 대해 생성된 모든 Pull Request에 대해 실행하기 위해 Github 앱으로 설치되는 Flask-Celery-Redis 다중 컨테이너 애플리케이션입니다.
Flask 컨테이너는 blueprints.py에 정의된 API 경로를 노출하여 서비스의 진입점입니다. API 경로에서 Pull 요청 페이로드가 수신되면 서비스는 Celery 컨테이너가 Pull 요청의 diff를 선택하고 스캔할 수 있도록 Redis 대기열로 페이로드를 전달합니다. 셀러리 컨테이너는 지정된 비밀 정규식을 검색한 후 PR에 댓글을 달고, Slack은 보안 팀 채널에 알리거나 팀이 후속 조치를 취할 수 있도록 JIRA 티켓을 생성합니다. Github 앱은 Flask API URL과 페이로드 SHA 체크섬을 생성하는 데 사용되는 공유 비밀로 구성됩니다.
API URL을 설정할 수 있는 한 가지 방법은 이 코드를 호스트에 배포하고 애플리케이션 로드 밸런서를 이 호스트에 할당하는 것입니다.
참고: 앱을 생성할 때 Deadshot 컨테이너를 배포할 호스트에 대한 DNS와 웹훅 비밀에 대한 보안 비밀 문자열이 준비되어 있는지 확인하십시오.
Github 관리자는 Deadshot 애플리케이션을 실행하거나 배포하기 전에 Github에서 Github 앱을 생성하고 설치해야 합니다. Github 앱 생성에 대해 더 자세히 알고 싶으시면 이 가이드를 읽어보세요.
앱 이름: deadshot(모두 소문자입니다. 서비스가 이 이름을 사용하여 PR에 대한 이전 댓글을 가져오기 때문에 중요합니다.)
웹훅 URL: http(s)://your-hosted-deadshot-dns/api/v1/deadshot-webhook
이를 로컬에서 테스트하려면 Github 앱 웹후크 섹션에 피드할 ngrok 엔드포인트를 생성할 수 있습니다.
이 애플리케이션이 작동하려면 Github 앱이 Github 앱의 권한 페이지에서 다음 권한과 구독을 활성화해야 합니다. 리포지토리 권한:
다른 모든 권한은 기본값인 액세스 권한 없음으로 변경되지 않고 그대로 유지됩니다.
이벤트를 구독하세요:
마지막으로 “GitHub 앱 만들기”를 클릭하세요. 앱이 성공적으로 생성된 후 앱 웹 페이지 상단 섹션에 있는 "개인 키 생성" 링크를 따르세요.
개인 키가 생성되면 안전한 위치에 보관하세요. 생성된 개인 키는 앱 상호작용을 위한 세션 토큰을 생성하는 데 사용되는 데이터 중 하나입니다.
개인 키를 생성한 후 모니터링하려는 모든 조직에 앱을 설치합니다.
이는 /bin/run.sh를 통해 세 개의 컨테이너(Flask, Celery, Redis)를 모두 가져오도록 설계된 다중 컨테이너 애플리케이션이므로 Dockerfile 이미지를 실행하면 애플리케이션 전체가 불러와야 합니다.
아래 세 가지 변수는 사용자가 제공한 단일 문자열 값입니다.
아래 환경 변수는 자격 증명이 포함된 파일의 경로를 로드합니다. 애플리케이션을 실행하기 전에 여기에서 사용 가능한 파일에 json 파일 키 값을 로드하세요.
참고: JSON 비밀 파일 위치를 이동하지 않으면 Dockerfiles 또는 docker-compose.yaml에 이미 있는 위의 세 가지 환경 변수 값을 업데이트할 필요가 없습니다.
이 명령은 docker-compose.yaml을 사용하여 모든 컨테이너를 불러옵니다. 아래 명령을 실행하기 전에 구성/환경/localdev.env를 조직과 관련된 값으로 업데이트하세요.
make serve이 작업을 완료하고 애플리케이션 제공을 위해 Dockerfile을 사용하지 않으려면 "서버 상태 확인" 섹션으로 이동하세요.
Dockerfile을 빌드하고 실행하는 방법에는 두 가지가 있습니다. 저장소에는 4개의 Dockerfile이 있으며 그 중 3개는 이 서비스가 작동하는 데 필요한 각 컨테이너에 대한 개별 이미지를 생성하는 데 사용되며, 네 번째는 Dockerfile 설정으로 다음 중 하나를 불러오는 데 사용할 수 있는 이미지를 생성합니다. 제공된 DEADSHOT_RUN_MODE 환경 변수 값(api 또는 작업자)에 따라 Flask 애플리케이션 또는 셀러리 작업자 아래 단계를 실행하려면 저장소의 루트 폴더에 있어야 합니다.
참고: Dockerfile.api 및 Dockerfile.celery 파일의 환경 변수를 업데이트했는지 확인하세요.
이 단계와 관련된 세 가지 Dockerfile이 있습니다. Dockerfile.api, Dockerfile.celery 및 Dockerfile.redis
docker build -f Dockerfile.api -t deadshot-api:<version> .
docker build -f Dockerfile.celery -t deadshot-worker:<version> .
docker build -f Dockerfile.redis -t deadshot-redis:<version> .
이전 단계에서 구축된 세 개의 이미지는 모두 별도의 네트워크에서 실행되므로 서로 통신할 수 없습니다. 컨테이너 간 통신을 활성화하려면 이를 컨테이너 네트워크에 추가해야 합니다.
docker network create deadshot-network
생성된 네트워크를 사용하여 다음 순서로 이미지를 실행합니다. Redis 컨테이너를 시작합니다.
docker run --net deadshot-network --name redis deadshot-redis:<version>
셀러리 컨테이너를 시작합니다.
docker run --net deadshot-network deadshot-worker:<version>
Flask API 컨테이너를 시작합니다.
docker run --net deadshot-network -p 9001:9001 deadshot-api:<version>
DEADSHOT_RUN_MODE 환경 변수를 기반으로 API 및 셀러리 작업자를 불러오기 위한 단일 Docker 이미지를 빌드하려면
make build이 명령은 서비스에 필요한 Redis 이미지도 생성합니다.
빌드된 이미지가 DEADSHOT_RUN_MODE=api 환경 변수로 실행되면 Flask 애플리케이션이 실행됩니다. 이미지가 DEADSHOT_RUN_MODE=worker 환경 변수로 실행되면 셀러리 작업자가 시작됩니다.
이제 API가 브라우저에서 http://localhost:9001/api/v1/heartbeat 로 이동하는 요청을 수신할 준비가 되었으므로 유효한 응답을 반환하거나 컬을 수행할 수 있습니다.
curl localhost:9001/api/v1/healthcheck 둘 다 다음 메시지를 표시해야 합니다: {"healthcheck": "ready"}
끌어오기 요청에 대한 Github 앱의 웹후크 페이로드가 있는 경우 로컬에서 다음 컬 명령을 실행하여 애플리케이션을 테스트할 수 있습니다.
curl -X POST -H " content-type: application/json " -H " X-GitHub-Enterprise-Host: github.mockcompany.com " -H " X-Hub-Signature: sha1=85df4936c6396c149be94144befab41168149840 " -H " X-GitHub-Event: pull_request " -d @tests/fixtures/good_pr.json http://localhost:9001/api/v1/deadshot-webhook도구가 다른 유형의 비밀을 모니터링하도록 하려면 regex.json 파일에 정규식을 추가하세요.
참고: 엔트로피 확인 플래그를 사용하면 정규식 일치 외에도 높은 엔트로피 결과를 찾을 수 있습니다.
현재 Deadshot은 Github Enterprise에서만 테스트되었지만 Github 클라우드에서도 작동해야 합니다.
