allow 규칙 표준

일반적인 관행에 따라, 귀사의 Rego 보험 약관 파일에는 ‘ allow ’ 조항이 반드시 포함되어야 합니다. 이 파이프라인의 맥락에서 볼 때, 이는 단순한 제안이 아니라 엄격한 요구 사항입니다.

파이프라인 엔진은 배포 여부를 최종적으로 결정하기 위해 특히 allow 부울 값을 조회합니다. 사용자 정의 Rego 정책을 제공하는 경우, 이 규칙을 명시적으로 정의해야 합니다. allow 규칙이 없거나, 해당 규칙의 평가 결과가 false``인 경우, 파이프라인은 즉시 중단되고 배포가 차단되며, 사용자가 정의한 거부 메시지가 출력됩니다.

최상의 보안을 보장하기 위해 OPA는 엄격한 “실패 시 차단(fail-closed)” 모델을 적용하여 운영됩니다. 정책은 항상 기본적으로 ‘ false ’로 설정되어야 하며, 필요한 모든 준수 조건이 충족된 경우에만 ‘ true ’로 평가되어야 합니다.

package one_pipeline.config
# Default deny
default allow := false
# Allow only if your custom checks pass
allow {
    check_sast_scans_passed
    check_secrets_scans_passed
}

정책 파일 및 데이터 유효성 검사 파일

정책 파일(.rego)- 논리

여기에는 실제 규칙과 조건을 작성합니다. 예를 들어, 정책에 다음과 같이 명시되어 있을 수 있습니다. “취약점 스캔이 완료되었고, 그 결과 중대한 문제가 하나도 없는 것으로 확인되지 않는 한 이 배포를 허용하지 마십시오.” policy-path 파이프라인 환경 속성을 사용하여 사용자 정의 정책 파일을 지정할 수 있습니다. 정책 파일이 제공되지 않으면 파이프라인은 기본 정책 파일을 사용합니다.

데이터 유효성 검사 파일(.json)- 주요 내용

이 파일은 정적 참조 목록 역할을 합니다. Rego 규칙에 데이터를 직접 하드코딩하는 대신, 이 파일을 사용하여 허용된 이미지 레지스트리(us.icr.io 또는 eu.icr.io)나 특정 검사에서 제외되는 특정 저장소와 같은 승인된 변수 목록을 관리할 수 있습니다. evidence-checks-config-path 파이프라인 환경 속성을 사용하여 데이터 유효성 검사 파일을 제공할 수 있습니다. 데이터 유효성 검사 파일이 제공되지 않으면, 파이프라인은 기본 데이터 유효성 검사 파일을 사용합니다.

데이터 유효성 검사 파일 예시:

        package one_pipeline.config
        pre_deployment := {
            "com.ibm.prod_change_request": {
                "asset_type": [
                "*",
                "image"
                ],
                "source": [
                "prod",
                "stage"
                ],
                "target": [
                "prod",
                "stage"
                ],
                "recommended": [
                "*"
                ]
            }
        }
        post_deployment := {
            "com.ibm.prod_change_request": {
                "asset_type": [
                "*",
                "image"
                ],
                "source": [
                "prod",
                "stage"
                ],
                "target": [
                "prod",
                "stage"
                ],
                "recommended": [
                "*"
                ]
            }
        }

구성의 각 블록은 어떤 증거가 요구되는지, 그 증거가 어디에서 비롯되는지, 그리고 얼마나 엄격하게 적용되어야 하는지를 정확히 정의합니다.

• 증거 유형 ID(com.ibm.prod_change_request): 최상위 키는 평가 대상인 증거의 구체적인 범주를 나타냅니다. 일반적인 예로는 com.ibm.static-scan, com.ibm.unit-tests, 또는 com.ibm.image_signing 등이 있습니다.
• asset_type: 이 규칙이 적용되는 아티팩트의 유형을 정의합니다. 예를 들어, 이 규칙은 image 또는 repo 에만 적용될 수 있습니다. ["*"] 를 사용하면 해당 규칙이 모든 자산 유형에 적용됩니다.
• source (출처 환경): 증거가 어디에서 비롯되었는지를 정의합니다. 이는 특정 브랜치이거나 파이프라인 환경일 수 있습니다(예: ci-pipeline, stage, prod).
• target (대상 환경): 이 증거가 배포를 위해 검증되고 있는 대상 환경을 정의합니다(예: stage, prod). 소스 및 대상에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
• gating mode: 마지막 필드에는 해당 증거 유형에 적용할 게이팅 모드가 표시됩니다. 지원되는 게이팅 모드에 대한 자세한 정보는 여기에서 확인할 수 있습니다.

참고 : 모든 배포 전 검사는 pre_deployment :{} 배열에 정의되어야 하며, 모든 배포 후 검사는 post_deployment :{} 배열에 정의되어야 합니다. 또한 기본 정책 경로를 사용하는 경우, 데이터 유효성 검사 레지스트리 파일에 one_pipeline.config 패키지의 임포트를 반드시 포함해야 합니다.

JSON-Rego 변환 스크립트

이 파이프라인은 기존 JSON 데이터 유효성 검사 파일을 기본적으로 지원하지만, ‘정책-as-코드(policy-as-code)’ 표준을 완전히 도입하기 위해서는 향후 구성을 기본 Rego 형식으로 현대화해야 할 수도 있습니다.

이를 돕기 위해, 기존 JSON 데이터 유효성 검사 파일을 새로운 Rego 형식으로 자동으로 변환해 주는 독립형 유틸리티 스크립트를 제공합니다.

스크립트 위치: /opt/one-pipeline/polyglot/polyglot/translate-pipeline-config.sh

변환기 스크립트 사용 방법

이 스크립트는 로컬에서 또는 파이프라인 실행 중에 실행할 수 있습니다. 스크립트를 로컬에서 실행할 때는 대상 환경과 소스 환경을 명시적으로 지정해야 합니다.

# Convert a JSON config to Rego using named parameters
/opt/one-pipeline/polyglot/polyglot/translate-pipeline-config.sh \
  --input ./legacy-evidence-config.json \
  --output ./new-evidence-config.rego \
  --target-env prod \
  --source-env master

유연한 구성: 여러 개의 유효성 검사 파일

복잡한 환경에서는 대개 모듈식 규칙 집합이 필요합니다. 이를 지원하기 위해, 프로모션 검증 파이프라인을 통해 여러 구성에 대해 증거를 동시에 평가할 수 있습니다.

evidence-checks-config-path 매개변수에 여러 데이터 유효성 검사 파일의 경로를 쉼표로 구분된 목록 형태로 전달하여 여러 파일을 지정할 수 있습니다. 이 경우 파이프라인은 각 구성 파일에 대해 증거 페이로드를 평가하고, 파일마다 별도의 평가 테이블을 생성합니다. 그리고 PR의 댓글 섹션에서는 각 파일에 대한 평가 표가 별도의 댓글로 표시되어 있습니다.

자동화된 PR 피드백

가시성을 극대화하기 위해, 파이프라인은 사용자가 제공한 각 구성 파일을 기준으로 현재 증거 페이로드를 평가합니다. 평가가 완료되면 파이프라인이 자동으로 상세한 요약 및 평가 표를 생성하여 PR에 직접 첨부합니다.

여러 개의 데이터 유효성 검사 파일을 구성하면, 파이프라인은 각 파일에 대한 결과를 별도의 PR 댓글로 게시합니다. 이를 통해 검토자들은 결과물을 혼동하지 않고도 다양한 맥락에 걸친 준수 현황을 명확하고 포괄적으로 파악할 수 있습니다.

각 PR 댓글 안에는 다음 내용을 확인할 수 있습니다:

• 세 가지 평가표: 검증 결과에 대한 상세한 분석. 이 표를 읽는 방법에 대한 자세한 내용은 ‘증거 확인 표 이해하기’를 참조하십시오.
• 구성 링크: 해당 평가를 수행하는 데 사용된 특정 데이터 유효성 검사 파일 및 정책 파일에 대한 직접 링크로, 규칙에 대한 감사 및 문제 해결을 용이하게 해줍니다.

프로모션 검증 단계에서, 이 OPA 준수 점검은 현황 파악과 피드백을 목적으로 설계되었습니다. 귀하의 규칙에 위배되는 규정 준수 문제가 감지되더라도 파이프라인은 중단되거나 실패하지 않습니다. 대신, 파이프라인이 실행을 완료하고 상세한 결과를 PR에 게시합니다. 이를 통해 개발자는 모든 규정 준수 미비 사항에 대한 완전한 보고서를 받아볼 수 있으며, 빌드 과정 도중 오류가 발생하지 않도록 이를 수정할 수 있습니다.

table_results 객체 (PR 피드백용)

PR 댓글에 상세한 Markdown 테이블을 생성하기 위해, 파이프라인은 table_results 라는 특정 데이터 구조를 검색합니다.

정책에서 table_results 내부에 정확히 이 여덟 가지 필드를 포함하는 res 객체를 반환하면, 파이프라인이 이를 처리합니다. 이 도구는 출력을 안전하게 파싱하여, PR에서 볼 수 있는 깔끔하고 상세한 Markdown 테이블로 자동으로 변환합니다:

table_results contains res if {
    # ... your custom evaluation logic goes here ...
    
    # Map your findings to the contract structure
    res := {
        "RuleType":       "Required",       
        "AssetType":      "image",          
        "AssetId":        "12345678",      
        "EvidenceTypeId": "com.ibm.scan",   
        "Tool":           "zap",         
        "Status":         "failure",        
        "Source":         "ci-pipeline",    
        "Target":         "prod",           
    }
}

allow 규칙 (파이프라인 실행용)

앞서 언급했듯이, 이 계약의 두 번째 필수 조항은 ‘ allow ’ 규칙입니다.

이것이 왜 필요한가요?

table_results 가 규정 준수 점검 결과를 보고하는 역할을 담당하는 반면, ‘ allow ’ 규칙은 파이프라인을 실제로 중단시키는 킬 스위치 역할을 합니다. 파이프라인 엔진은 최종 진행/중단 결정을 내리기 위해 allow 부울 값을 조회하도록 하드코딩되어 있습니다.

사용자 정의 정책 파일을 제공하되 ‘ allow ’ 규칙을 포함하는 것을 잊어버리면, 파이프라인은 어떻게 진행해야 할지 알 수 없습니다. 엄격한 ‘실패 시 차단(fail-closed)’ 보안 모델을 따르므로, 기본적으로 파이프라인 실행을 실패로 처리하고 배포를 차단합니다.

OPA 활성화

CD 및 CC 파이프라인에서 OPA 기반 규정 준수 게이트를 활성화하려면, ‘ opt-in-rego-translation ’ 플래그를 명시적으로 켜야 합니다( true 또는 1 로 설정).

구성 제약 조건

프로모션 파이프라인과 마찬가지로, 정책 파일(로직)과 데이터 유효성 검사 파일(사실)을 모두 제공할 수 있습니다. 하지만 한 가지 중요한 차이점이 있습니다. 현재 CD 및 CC 파이프라인은 쉼표로 구분된 목록이 아닌, 한 번에 하나의 데이터 유효성 검사 파일만 처리할 수 있습니다.

변경 요청(CR) 첨부 파일 및 파이프라인 완료 단계

CD 파이프라인을 실행하면 엔진이 데이터 유효성 검사 파일을 처리하여 감사 목적으로 변경 요청에 첨부합니다. 파일 첨부 방식은 전적으로 사용자가 지정한 형식에 따라 달라집니다:

• 기존 JSON 데이터 유효성 검사 파일을 제공하는 경우: 파이프라인이 백그라운드에서 이를 자동으로 변환합니다. 원본 JSON 파일과 생성된 Rego 구성 파일 모두 ‘변경 요청’ 단계에 첨부되어 있습니다.
• 네이티브 Rego 데이터 유효성 검사 파일을 제공하는 경우: 파이프라인은 사용자가 제공한 Rego 파일만 직접 연결합니다.

파이프라인의 맨 마지막 단계인 ‘CD 완료’ 단계에서 이루어지는 구성 재구축 과정에도 이 똑같은 연결 방식이 적용됩니다.