파이프라인 내 IaC 사용자 정의 규칙

GitHub Actionsarrow-up-right와 같은 CI/CD를 사용하는 것은 사용자 정의 규칙을 관리, 배포 및 시행하는 데 이상적입니다.

파이프라인 내 IaC 사용자 정의 규칙 개요

이 예시는 보안 팀이 다음을 수행하는 방법을 보여줍니다:

  • 규칙을 GitHub 리포지토리에 저장

  • GitHub Actions를 사용하여 파이프라인에 다양한 개발 시점 단계를 추가

  • 사용자 정의 규칙을 사용하여 변경 사항을 제어(gate)하는 GitHub Action 파이프라인을 실행하도록 다른 GitHub 리포지토리를 구성

Snyk은 예시를 위해 snyk/custom-rules-examplearrow-up-right 리포지토리를 사용합니다; 이 리포지토리에는 SDK 시작하기를 진행하며 작성된 모든 사용자 정의 규칙이 포함되어 있습니다.

목표: 파이프라인을 다음과 같이 구성합니다:

  • 새로운 규칙이나 기존 규칙의 변경 사항이 기존 기능을 손상시키지 않는지 확인합니다.

  • main의 규칙을 OCI 레지스트리에 게시합니다.

  • 다른 파이프라인에서 사용자 정의 규칙 사용을 시행합니다.

  • 선택 사항: 환경 변수를 사용하여 사용자 정의 규칙을 구성합니다.

GitHub Action을 사용하여 PR 검사 추가

PR 검사의 예시는 https://github.com/snyk/custom-rules-example/pull/5arrow-up-right에서 볼 수 있으며, 여기서는 my_rule이라는 새로운 규칙을 추가하려고 시도합니다. 이는 규칙 작성 방법 배우기에 나오는 것과 동일한 규칙입니다.

이 규칙이 예상대로 작동하는지 확인하기 위해 단위 테스트가 구현되었습니다. PR 검사의 일부로 단위 테스트를 실행하기 위해, .github/workflows 아래에 test.yml이라는 GitHub Action이 이전에 구성되었습니다:

이 워크플로우에 대해 주목해야 할 몇 가지 사항:

  • main이 아닌 모든 브랜치에서 실행되도록 구성되어 있으므로, PR이 열려 있을 때 실행됩니다.

  • npm을 사용하여 snyk-iac-rules SDK를 설치할 수 있도록 Node.js 환경을 설정하는 단계들이 추가되었습니다.

  • snyk-iac-rules test를 실행하는 단계가 추가되었으며, 테스트 중 하나라도 실패하면 PR 검사가 실패하게 됩니다.

circle-info

main 브랜치에 직접 푸시할 수 없도록 Settings -> Branches에서 main 브랜치를 먼저 구성해야 합니다.

Snyk IaC GitHub Action

규칙을 테스트하는 또 다른 방법은 Snyk IaC GitHub Actionarrow-up-right을 사용하여 Snyk CLI로 계약(contract)을 테스트하는 것입니다. 이를 통해 생성된 번들이 CLI에서 읽을 수 있는지 확인합니다.

이를 수행하려면 Snyk CLI를 설치하는 단계와 Snyk 계정 설정에서 찾을 수 있는 SNYK_TOKEN이 필요합니다.

이러한 테스트를 확장하여 Shellspecarrow-up-right을 사용하고 원하는 취약점이 트리거되는지 확인할 수도 있지만, Snyk은 이를 위해 단위 테스트를 사용할 것을 권장합니다.

사용자 정의 규칙 게시

PR이 이전 섹션의 검사를 통과하고 main 브랜치에 병합되면, Snyk 규칙을 OCI 레지스트리에 게시할 수 있습니다. 이를 통해 별도의 파이프라인을 구성하고, 이 위치에서 사용자 정의 규칙 번들을 다운로드한 다음, 잘못된 구성을 포착하기 위해 사용자 정의 규칙을 실행할 수 있습니다.

이를 위해 .github/workflows 아래에 publish.yml이라는 또 다른 워크플로우를 추가하십시오:

이전 워크플로우와 비슷해 보이지만, 주목해야 할 몇 가지 사항이 있습니다:

  • main 브랜치에서만 실행되도록 구성되어 있으므로, PR이 병합될 때 실행됩니다.

  • 선택한 OCI 레지스트리인 Docker Hub에 인증하는 단계가 추가되었습니다. 지원되는 레지스트리 목록은 번들 푸시하기를 참조하십시오. 이를 위해 docker/login-actionarrow-up-right GitHub Action을 사용하고 Settings -> Secrets에서 GitHub 시크릿을 구성해야 합니다.

  • snyk-iac-rules build 실행 후 snyk-iac-rules push를 실행하는 단계가 추가되었으며, 이는 생성된 사용자 정의 규칙 번들을 OCI 레지스트리에 게시합니다.

규칙 버전 관리

모든 CI/CD 파이프라인에 영향을 주지 않고 사용자 정의 규칙의 실험적 버전을 릴리스하려면 태그를 사용하여 번들의 버전을 관리하십시오.

대부분의 서비스에서 여전히 v1을 사용하는 동안 번들 v2-beta 시험을 시작하십시오:

circle-info

이 워크플로우를 사용하려면 GitHub Secrets에 구성된 OCI_REGISTRY_NAME에 태그나 프로토콜이 이미 포함되어 있지 않은지 확인하십시오.

사용자 정의 규칙 시행

사용자 정의 규칙을 OCI 레지스트리에 게시한 후, 이 규칙을 사용하도록 별도의 파이프라인을 구성할 수 있습니다.

이를 수행하는 한 가지 방법은 API 엔드포인트 그룹의 Infrastructure as Code 설정 업데이트를 사용하는 것입니다.

이는 구성된 사용자 정의 규칙 번들을 사용하도록 Snyk을 업데이트하기 위해 위에서 언급한 GitHub Action에 또 다른 작업을 구성하는 것을 의미합니다:

이 API 호출은 선택한 Snyk 그룹과 그 하위의 모든 조직이 구성된 사용자 정의 규칙 번들을 사용하도록 업데이트합니다.

circle-info

조직이 v2-beta와 같은 다른 번들을 사용하도록 구성하려면 Snyk 설정 페이지를 사용하십시오. 새 번들을 구성하거나 사용자 정의 규칙을 비활성화하여 CI/CD 파이프라인에서 환경 변수를 사용하여 사용자 정의 규칙을 실행하도록 할 수 있습니다.

다른 리포지토리에서 이 그룹 아래의 조직 중 하나로 인증하고 워크플로우에 Snyk IaC GitHub Action을 추가하십시오:

그 결과 생성된 잘못된 구성이 해결될 때까지 GitHub Action이 실패하게 됩니다:

사용자 정의 규칙 구성

API나 Snyk 설정 페이지를 사용하는 것이 너무 제한적으로 보일 경우, Snyk은 환경 변수를 사용하여 사용자 정의 규칙을 구성하는 방법도 제공합니다.

You can use the Snyk IaC GitHub Action with the SNYK_CFG_OCI_REGISTRY_URL, SNYK_CFG_OCI_REGISTRY_USERNAME, and SNYK_CFG_OCI_REGISTRY_PASSWORD environment variables to scan your configuration files for any custom rules that may have been breached.

The GitHub Action reads these environment variables and pulls down the bundle pushed in the previous step to the configured OCI registry. The GitHub action looks like this:

Last updated