Pixi-CRS가 클라우드로 이동 - 파트 5: GitHub Actions

Pixi-CRS를 구현한 네 번째 파이프라인은 GitHub Actions(GHA): https://github.com/features/actions 입니다.

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

Pixi-CRS는 GitHub Actions에서 다음과 같이 표시됩니다.

Pixi-CRS 파이프라인 코드

GitHub Actions는 이 시리즈의 이전 블로그 게시물에서 설명한 것과 같은 클라우드 공급자가 아닙니다. GitHub Actions는 "단지"CI/CD 파이프라인이지만 구성하기가 매우 쉽고 따라서 매우 가볍습니다. 나는 그것을 좋아한다!
파이프라인 뒤의 코드를 찾을 수 있습니다here.
GitHub Actions는 리포지토리의 ./github/workflows 하위 디렉터리에 있는 yaml 파일에 작성됩니다. GitHub Actions를 시작하는 것은 매우 쉽습니다. 아무것도 구성할 필요가 없습니다. 명명된 디렉터리에 yaml 파일을 추가하는 것으로 충분하며 작업을 실행할 수 있습니다.

./github/workflows/pixi-crs-ci.yml 파일을 자세히 살펴보겠습니다.

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

name: Pixi-CRS CI Pipeline

# Trigger the workflow on push
# and pull requests
on: [push, pull_request]

jobs:
  build:
    name: Start Pixi and the CRS
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@master

#      - name: Debugging 
#        run: pwd
#      - name: Debugging 
#        run: ls

      - name: Starting Pixi and CRS with docker-compose up
        run: docker-compose -f docker-compose.yaml --env-file compose-gcp.env up -d

        # Application Tests with Testcafe
        # skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
      - name: Run Testcafe Tests Pixi without and with CRS
        run: docker run --volume /home/runner/work/pixi-crs/pixi-crs/testcafe/tests_container_ip:/tests --rm testcafe/testcafe --skip-js-errors 'chromium:headless --no-sandbox'

        # Show Full error.log
      - name: Show ModSecurity logs
        run: docker exec crs cat /var/log/apache2/error.log

        # ModSecurity Log Analysis:
        # 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
      - name: Fail if ModSecurity logs are not empty
        run: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep -vi MyEvilWAFTest | grep -v 949110 | grep -v 980130 | grep msg; then echo "False Positive Found! Aborting!" && exit 1 ; else echo "ModSecurity Logs empty. This is good!"; fi

        # Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
        # That means CRS is not working properly or test was aborted.
      - name: Fail if WAF Test String is missing in ModSecurity logs
        run: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep MyEvilWAFTest; then echo "WAF Test String Found. This is good!"; else echo "WAF Test String not Found! Aborting!" && exit 1; fi

파이프라인 단계

Pixi 및 CRS 시작

하나의 docker-compose up 명령으로 Pixi와 CRS를 시작하고 --env-file을 제공합니다. 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 파이프라인이고 모든 푸시 및 풀 요청 후에 GitHub Actions를 실행하려고 하므로 트리거를 구성해야 합니다.
다음 줄을 추가하여 our ./github/workflows/pixi-crs-ci.yml file에 이것을 추가했습니다.

# Trigger the workflow on push
# and pull requests
on: [push, pull_request]

언급할 사항

Pixi-CRS는 CI 파이프라인이고 CD 부분은 제가 설정하지 않았습니다.
이 블로그에서는 CI 부분만 보여드리고 싶었습니다.

다음 블로그 게시물

이 시리즈의 다음이자 마지막 블로그 게시물에서는 CircleCI, Amazon Web Services, Azure DevOps, Google Cloud Platform 및 GitHub Actions에서 사용 가능한 5가지 Pixi-CRS 파이프라인을 모두 요약하고 비교할 것입니다.