배포 자격 증명에 하나의 좁은 작업 부여

자동화와 개인 관리를 분리

보고 API 파이프라인은 승인된 아티팩트를 선택하고 통제된 릴리스 작업을 호출해야 합니다. 그렇다고 해서 자동으로 사용자 생성, 결제 변경 또는 모든 애플리케이션 시크릿 읽기가 필요한 것은 아닙니다. 권한 인벤토리와 보호된 테스트 환경으로 시작하고, 자격 증명을 문서, 저장소 및 예시 로그에 두지 마십시오.

배포 자격 증명을 폐기해도 유일한 조사 경로가 제거되지 않도록 사람의 복구 접근은 별도로 유지해야 합니다. 권한 있는 유지관리자와 독립적인 호스트 검증을 식별하십시오. 두 번째 무제한 키는 더 좁은 역할이 아니라 또 다른 자격 증명입니다.

허용되는 작업을 정확히 설명

릴리스 작업의 입력을 검증하십시오. 임의 텍스트를 권한 있는 셸로 연결하는 제한된 명령은 여전히 의도하지 않은 작업을 허용합니다. 래퍼 동작, 쓰기 가능 경로 및 아티팩트 신뢰를 함께 검토하십시오. 광범위한 sudo 권한이나 Docker 소켓에 대한 접근은 의도된 경계를 무력화할 수 있습니다.

워크플로 편집을 자격 증명 접근으로 간주

신뢰할 수 있는 워크플로 단계를 변경할 수 있는 사람은 자신의 자격 증명을 사용하거나 노출할 수 있습니다. 저장소 권한, 보호된 배포 환경, 권한 있는 작업을 실행하는 이벤트를 검토하세요. 프로덕션 자격 증명을 신뢰할 수 없는 풀 리퀘스트 코드와 격리하세요. 워크플로 토큰에는 해당 작업에 필요한 권한만 부여하세요.

GitHub는 불변 액션 선택을 위해 전체 길이 커밋 SHA 고정을 권장합니다. 선택한 액션과 이후 업데이트를 검토하세요. 버전 태그는 이동할 수 있습니다. 신뢰할 수 없는 이벤트 데이터를 인라인 셸 코드에 직접 삽입하지 마세요. 알려진 시크릿 값을 마스킹하는 것은 변환, 로그 또는 아티팩트를 통한 공개를 보장하지 않습니다.

기술 참조: GitHub Actions 보안 사용.

대상이 지원하는 경우 짧은 수명 사용

OpenID Connect를 사용하면 지원되는 대상이 워크플로 ID를 단기 자격 증명으로 교환할 수 있습니다. 의도한 저장소, 브랜치 또는 환경 및 대상에 대한 신뢰 검사를 구성하세요. 이는 범용 SSH 대체가 아니며 현재 PrivacyNodes 프런트엔드에서 제공하는 기능도 아닙니다.

배포에서 SSH을 사용하는 경우 설치된 패키지의 authorized-key 옵션을 검토하세요. 강제 명령만으로는 포워딩을 금지할 수 없습니다. 제한은 의도한 접근 경로를 포함해야 하며 안전한 릴리스 작업을 여전히 호출해야 합니다. 별도 환경에서 테스트하세요. 인증을 변경하는 동안 작동하는 관리 및 복구 접근을 유지하고, 기존 방법을 제거하기 전에 새 독립 연결을 확인하세요.

기술 참조: GitHub Actions OpenID Connect · OpenSSH authorized_keys 형식.

허용 및 금지 작업 테스트

ID가 의도한 아티팩트를 선택하고 릴리스를 호출하며 유용한 결과를 얻을 수 있는지 확인하세요. 그런 다음 한계를 테스트하세요. 다른 애플리케이션의 시크릿, 관련 없는 파일 변경, 임의 관리는 사용할 수 없어야 합니다. 래퍼가 거부해야 하는 아티팩트 경로와 인수를 포함하세요.

ID, 범위, 해당되는 경우 만료, 승인 유지관리자, 감사 증거 위치를 기록하세요. 자격 증명 값 대신 저장소 참조를 유지하세요. 테스트가 광범위한 관리를 부여한 후에만 작동한다면, 이를 조용히 영구 역할로 만들지 말고 릴리스 작업을 재검토하세요.

폐기 및 파이프라인 중단 릴리스 리허설

검토된 범위로 대체품을 준비하고 테스트 배포를 확인한 후 파이프라인을 전환하고 이전 ID를 폐기하세요. 대체된 자격 증명이 실패하고 다른 워크플로에 중복이 남지 않는지 확인하세요. 새 키를 추가하는 것만으로는 이전 접근이 제거되지 않습니다.

권한 있는 유지관리자가 배포를 중단하고 CI를 사용할 수 없을 때 복구하는 방법을 문서화하세요. 해당 절차를 릴리스 기록 및 복구 인벤토리에 연결하세요. 좁은 자격 증명은 의도한 권한을 제한하지만 악성 아티팩트를 무해하게 만들지는 않습니다.