규칙 작성

Rego의 규칙

규칙은 Rego로 작성됩니다. Rego를 작성할 때 다음 두 가지 작업을 수행합니다:

1. 정책 결정을 내리는 규칙을 작성합니다. 규칙은 조건부 할당입니다.

2. 규칙을 정책으로 구성합니다. 정책은 계층적 이름을 가진 규칙 집합입니다.

정책 언어에 대한 자세한 내용은 OPA 정책 언어 문서 페이지를 참조하십시오.

OPA Playground를 사용하여 Rego를 시도하거나 이 가이드의 예시를 실행할 수도 있습니다.

새 규칙 생성 방법

시작하는 데 두 가지 옵션이 있습니다:

1. template 명령을 사용하여 규칙 작성을 위한 필수 파일을 생성합니다:

   snyk-iac-rules template --rule <RULE-NAME> --format <hcl2|json|yaml|tf-plan>

   이는 제공된 구성 형식에 따라 픽스처 파일을 포함하여 규칙에 대한 스캐폴딩을 생성합니다. 자세한 내용은 template 명령에 대한 설명서를 참조하십시오.

2. Rego 정책을 처음부터 작성하고 예상되는 파일 및 폴더 구조를 직접 일치시킵니다: rules └── my_rule ├── main.rego └── main_test.rego

template 명령을 사용하지 않으면 자체 Rego 테스트 프레임워크를 작성해야 합니다.

규칙의 구조

Rego에서 다음과 같이 요청을 허용하거나 거부하는 문을 작성할 수 있습니다: allow { input.name == "alice" } 또는 deny { input.name == "alice" }

template 명령을 사용하여 규칙을 생성한 경우 기본 진입점(entry point)은 **rules/deny**입니다. 이를 재정의하고 deny와 다른 이름을 사용하려면 번들 규칙 섹션을 참조하십시오.

snyk-iac-rules template --rule NEW-RULE --format hcl2를 실행할 때 생성되는 거부 규칙의 스켈레톤은 다음과 같습니다:

rules/NEW-RULE/main.rego

package rules

deny[msg] {
	resource := input.resource.test[name]
	resource.todo
	msg := {
		# 필수 필드
		"publicId": "NEW-RULE",
		"title": "기본 제목",
		"severity": "low",
		"msg": sprintf("input.resource.test[%s].todo", [name]),
		# 선택 필드
		"issue": "",
		"impact": "",
		"remediation": "",
		"references": [],
	}
}

Snyk IaC CLI에서 출력이 올바르게 표시되도록 msg 속성의 이 형식을 따라야 합니다.

속성은 다음과 같습니다:

• publicId: 회사-001과 같이 팀에 고유한 명명 규칙입니다. 내부 Snyk 규칙과 구별하기 위해 "SNYK-"를 포함하거나 시작해서는 안 됩니다.

• title: 이슈를 요약하는 짧은 제목입니다.

• severity: low/medium/high/critical 중 하나일 수 있습니다.

• msg: Snyk은 리소스 이름과 속성만 변경할 것을 권장합니다. 예를 들어, input.aws_s3_bucket[%s].tags를 예시와 일치시킵니다. sprintf 함수는 Rego에서 제공되며 Snyk이 이슈가 발견된 정확한 위치를 설명하는 동적 오류 메시지를 제공할 수 있도록 합니다.

다음 속성은 선택 사항이지만 Snyk CLI에서 스캔 결과를 향상시키는 데 사용할 수 있습니다:

• issue: 정확한 이슈가 무엇인지에 대한 더 자세한 문자열 설명입니다.

• impact: 이 이슈를 해결하지 않을 경우의 영향에 대한 더 자세한 문자열 설명입니다.

• remediation: 이슈 해결 방법에 대한 더 자세한 문자열 설명입니다. Snyk은 여기에 코드 스니펫을 제공할 것을 권장합니다.

• references: 문서에 대한 URL이 포함된 문자열 배열을 제공할 수 있습니다.

규칙에 대해 생성된 테스트는 두 개의 생성된 Terraform 파일을 사용하여 허용되거나 거부된 픽스처에 대해 규칙이 올바른 msg 필드를 반환하는지 확인합니다:

package rules

import data.lib
import data.lib.testing

test_NEW_RULE {
	# 규칙이 허용되는 테스트 케이스를 포함하는 배열
	allowed_test_cases := [{
		"want_msgs": [],
		"fixture": "allowed.tf",
	}]

	# 규칙이 거부되는 테스트 케이스를 포함하는 배열
	denied_test_cases := [{
		# 거부된 규칙에 의해 올바른 메시지가 반환되는지 확인
		"want_msgs": ["input.resource.test[denied].todo"],
		"fixture": "denied.tf",
	}]

	test_cases := array.concat(allowed_test_cases, denied_test_cases)
	testing.evaluate_test_cases("NEW-RULE", "./rules/NEW-RULE/fixtures", test_cases)
}

규칙 예시

더 많은 예시는 사용자 정의 규칙 예시를 참조하십시오.

이 예시에서는 리소스에 owner 태그가 없을 때 msg를 할당하도록 템플릿 규칙이 수정되었습니다:

rules/MY_RULE/main.rego

package rules

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
    not resource.tags.owner
	
    msg := {
        "publicId": "MY_RULE",
        "title": "태그에서 소유자 누락",
        "severity": "medium",
        "msg": sprintf("input.resource.aws_redshift_cluster[%s].tags", [name]),
        "issue": "",
        "impact": "",
        "remediation": "",
        "references": [],
    }
}

제한 사항 및 참고 사항

• Snyk은 Rego 정책을 Wasm 모듈로 컴파일하므로 Wasm을 지원하는 빌트인 함수만 사용할 수 있습니다. 정책 참조 문서 하단에 이러한 함수를 식별하는 데 도움이 되는 표가 있습니다.

• 규칙은 동일한 이름으로 여러 번 정의될 수 있습니다. 예를 들어, 파일 내 또는 동일한 패키지 아래의 별도 파일에서 정의될 수 있습니다.

packages rules

deny[msg] {
    resource.this
}
...

deny[msg] {
    resource.that
}
...

이러한 규칙은 각 정의가 추가적이기 때문에 점증적(incremental)이라고 합니다. 정책 참조 문서에서 점증적 정의에 대해 자세히 알아볼 수 있습니다. 이러한 동일한 이름의 규칙은 다른 값을 반환해야 하며, 그렇지 않으면 OPA가 오류를 반환한다는 점에 유의하십시오. 정책 참조 문서에서 완전 정의에 대해 자세히 알아볼 수 있습니다.

더 복잡한 주제는 OPA가 충돌 해결(Conflict Resolution)을 해결하는 방법을 확인하십시오.