Pixi-CRS가 클라우드로 이동 - 4부: Google Cloud Platform

Pixi-CRS를 옮긴 세 번째 클라우드 제공업체는 Google Cloud Platform(GCP): https://console.cloud.google.com/

이것은 "Pixi-CRS가 클라우드로 이동"시리즈의 네 번째 블로그 게시물입니다.

Pixi-CRS는 Google Cloud Platform에서 다음과 같이 표시됩니다.



위의 이미지에서 GCP의 Pixi-CRS CI 파이프라인이 GCP Cloud Build로 구성되었음을 알 수 있습니다.

Pixi-CRS 파이프라인 코드

파이프라인 뒤의 코드를 찾을 수 있습니다here.
GCP Cloud Build 코드는 저장소의 루트 디렉터리에 있는 cloudbuild.yaml 파일에 작성됩니다. GCP에서 새 Cloud Build를 만드는 것은 매우 쉽습니다. 먼저 프로젝트를 만들고 "클라우드 빌드 활성화"를 해야 했습니다.

이 cloudbuild.yaml 파일을 자세히 살펴보겠습니다.

아래에서 다른 단계를 설명하겠습니다. 그러나 제공된 yaml 파일의 주석에서도 설명을 제공합니다.

# Google Cloud cloudbuild.yaml
#
steps:
# Start the OWASP ModSecurity Core Rule Set and Pixi with its DB with docker-compose
# OWASP ModSecurity Core Rule Set Container (Apache Reverse Proxy)
# owasp/modsecurity-crs
# See https://coreruleset.org/
# ModSecurity Tuning:
# See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/
- id: 'Starting Pixi and CRS with docker-compose up'
  name: 'docker/compose:1.26.2'
  args: ['--env-file', '/workspace/compose-gcp.env', 'up', '-d']

# Debugging possibilities
#- name: 'ubuntu'
#  args: [ "touch", "foo" ]
#- name: 'ubuntu'
#  args: [ "ls", "-l", "/workspace/testcafe/tests_container_ip" ]
#- name: 'ubuntu'
#  args: [ "pwd" ]
# Debugging with curl
#- name: 'curlimages/curl:7.69.0'
#  args: [ "-v", "http://172.17.0.1:8000/register"]
#- name: 'curlimages/curl:7.69.0'
#  args: [ "-v", "http://172.17.0.1:8080/register"]

# Application Tests with Testcafe
# skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
- id: 'Run Testcafe Tests: Pixi without and with CRS'
  name: 'gcr.io/cloud-builders/docker'
  args: [ "run", "--volume", "/workspace/testcafe/tests_container_ip:/tests", "--rm", "testcafe/testcafe", "chromium:headless --no-sandbox", "--skip-js-errors" ]

# Copy ModSecurity Logs:
- id: 'Copy ModSecurity logs'
  name: 'gcr.io/cloud-builders/docker'
 # args: [ "exec", "crs", "cat /var/log/apache2/error.log | grep ModSecurity" ]
  args: [ "cp", "crs:/var/log/apache2/error.log", "/workspace/error.log" ]

# Show ModSecurity Logs
- id: 'Show ModSecurity logs'
  name: 'ubuntu'
  args: [ "cat", "/workspace/error.log" ]

# ModSecurity Log Analysis:
# Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
# That means CRS is not working properly or test was aborted.

- id: 'Fail if ModSecurity log does not contain WAF Test String'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: "bash"
  args:
    - "-c"
    - |
        cat /workspace/error.log | grep -q MyEvilWAFTest
# Fail if ModSecurity log is not empty
# Show ModSecurity logs of Testcafe Tests
# If not empty -> Repair your application OR
#              -> ModSecurity Tuning:
# See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ OR
#              -> GitHub issue: https://github.com/SpiderLabs/owasp-modsecurity-crs
- id: 'Fail if ModSecurity log is not empty'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: "bash"
  args:
    - "-c"
    - |
        "cat /workspace/error.log grep ModSecurity | grep error | grep -vi MyEvilWAFTest | grep -v 949110 | grep -v 980130 && exit 1 || exit 0"
#- id: 'Fail if ModSecurity log is not empty'
#  name: 'gcr.io/cloud-builders/docker'
#  args: [ 'exec', 'crs', 'cat /var/log/apache2/error.log | grep ModSecurity | grep error | grep -vi "MyEvilWAFTest" | grep -v "949110" | grep -vi "980130" && exit 1 || exit 0' ]


# Debugging docker
#- id: 'Docker'
#  name: 'gcr.io/cloud-builders/docker'
#  args: [ "ps" ]

파이프라인 단계

Pixi 및 CRS 시작

하나의 docker-compose up 명령으로 Pixi와 CRS를 시작하고 --env-file을 제공합니다. docker/compose 이미지를 사용하므로 Docker 또는 docker-compose를 설치할 필요가 없습니다.

테스트카페 테스트

이제 CRS와 Pixi가 실행 중이므로 Testcafe 테스트를 수행합니다. 이번에는 testcafe/testcafe Docker 컨테이너로 테스트를 실행할 수 있습니다. 테스트는 이 컨테이너에 쉽게 탑재할 수 있습니다.
다시 말하지만 먼저 Pixi를 직접 테스트한 다음 CRS를 통해 Pixi를 테스트합니다. 또한 악성 문자열로 CRS 자체를 테스트합니다. 우리는 WAF가 이를 차단하는지 확인하고 싶습니다.

테스트의 경우 Testcafe Docker 컨테이너 내부에서 호출하기 때문에 http://172.17.0.1:8000을 통해 Pixi를 호출하고 http://172.17.0.1:8080을 통해 CRS를 호출합니다.

Testcafe 테스트 결과는 다음과 같습니다.

결과 확인

결국 결과를 확인합니다. CRS Docker 컨테이너 내부의 ModSecurity 로그를 살펴봅니다.
이렇게 하면 합법적인 테스트에서 오탐지가 발생하지 않습니다. 또한 악의적인 테스트가 기록되었는지 확인합니다.

방아쇠

Pixi-CRS는 CI 파이프라인이고 리포지토리에 푸시할 때마다 GCP Cloud Build를 실행하려고 하므로 푸시 이벤트에 대한 트리거를 구성해야 합니다.
Cloud Build > Triggers > Create Trigger 옵션을 통해 이를 추가했습니다.

언급할 사항

Pixi-CRS는 CI 파이프라인이고 CD 부분은 제가 설정하지 않았습니다.
이번 블로그 포스트에서는 CI 부분만 보여드리고자 했습니다. 또한 훨씬 더 많은 Google Cloud Platform 옵션을 사용할 수 있다는 것도 알고 있습니다. 하지만 이 블로그 게시물에서는 간단하게 유지하고 Pixi-CRS CI 부분에 집중하고 싶었습니다.

다음 블로그 게시물

이 시리즈의 다음 블로그 게시물에서는 GitHub Actions에서 Pixi-CRS CI 파이프라인을 구현하겠습니다.