IaC 사용자 정의 규칙 예시

간단한 불리언(boolean) 규칙 예시

이 가이드의 전체 예시는 이 OPA Playground 및 snyk/custom-rules-example 리포지토리에서 찾을 수 있습니다.

SDK를 사용하여 새로운 규칙 CUSTOM-RULE-1을 생성했습니다(즉, snyk-iac-rules template --rule CUSTOM-RULE-1). 그리고 Terraform 리소스가 포함된 매우 간단한 픽스처 파일이 있다고 가정합니다:

rules/CUSTOM-RULE-1/fixtures/denied.tf

resource "aws_redshift_cluster" "denied" {
  cluster_identifier = "tf-redshift-cluster"
  node_type          = "dc1.large"
  tags = {
  }
}

이제 생성된 Rego를 수정하여 소유자 태그가 지정된 리소스를 강제합니다:

1. aws_redshift_cluster의 모든 리소스를 열거하는 [name] 변수를 생성합니다. 이 변수는 i, j, name 등 원하는 이름으로 지정할 수 있습니다.

2. 왈러스 연산자(:=)를 사용하여 값을 할당하여 resource := input.resource.aws_redshift_cluster[name]과 같이 리소스 변수에 저장합니다.

3. 각 리소스에 소유자 태그가 존재하는지 확인합니다. 이를 위해 resource.tags.owner 경로가 정의되어 있는지 확인합니다. 정의되어 있지 않으면 정의되지 않은 것으로 평가됩니다. 따라서 NOT 키워드를 앞에 사용하여 TRUE로 평가되도록 합니다. 예를 들어 not resource.tags.owner

수정된 Rego는 다음과 같습니다:

rules/CUSTOM-RULE-1/main.rego

package rules

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
    not resource.tags.owner

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

위에서 제공된 Terraform 파일을 Rego 코드가 어떻게 평가하는지 이해하려면 SDK가 픽스처 파일을 JSON으로 파싱하는 방법을 살펴보십시오.

Snyk은 단위 테스트 업데이트 및 실행을 통해 규칙이 올바른지 항상 확인하는 것을 권장합니다.

이 규칙에 대한 테스트는 이 가이드의 시작 부분에 있는 픽스처가 유효하지 않음을 Rego 규칙이 식별할 수 있는지 확인합니다:

rules/CUSTOM-RULE-1/main_test.rego

package rules

import data.lib
import data.lib.testing

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

	# 규칙이 거부되는 테스트 케이스를 포함하는 배열
	denied_test_cases := [{
		"want_msgs": ["input.resource.aws_redshift_cluster[denied].tags"],
		"fixture": "denied.tf",
	}]

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

논리 AND(logical AND) 예시

위의 예시를 확장하여 두 가지 조건을 모두 충족하는 모든 경우를 허용하도록 규칙을 업데이트해 보십시오:

1. 리소스에 "owner" 태그가 있습니다. AND

2. 리소스에 "description" 태그가 있습니다.

이 새로운 조건을 테스트하려면 template 명령을 사용하여 새 규칙 CUSTOM-RULE-2를 생성하고 다음 픽스처 파일을 작성합니다:

rules/CUSTOM-RULE-2/fixtures/denied.tf

resource "aws_redshift_cluster" "denied" {
  cluster_identifier = "tf-redshift-cluster"
  node_type          = "dc1.large"
  tags = {
    owner = "team-123"
  }
}

여러 표현식을 함께 연결하면 논리 AND를 표현합니다.

• ; 연산자로 이를 수행할 수 있습니다.

• 또는 여러 줄에 걸쳐 표현식을 분할하여 ; (AND) 연산자를 생략할 수 있습니다.

논리 AND는 OPA 문서에서도 다룹니다.

rules/CUSTOM-RULE-2/main.rego

package rules

aws_redshift_cluster_tags_present(resource) {
    resource.tags.owner
    resource.tags.description
}

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
    not aws_redshift_cluster_tags_present(resource)
    msg := {
        "publicId": "CUSTOM-RULE-2",
        "title": "태그에서 설명 및 소유자 누락",
        "severity": "medium",
        "msg": sprintf("input.resource.aws_redshift_cluster[%s].tags", [name]),
        "issue": "",
        "impact": "",
        "remediation": "",
        "references": [],
    }
}

Snyk은 단위 테스트 업데이트 및 실행을 통해 규칙이 올바른지 항상 확인하는 것을 권장합니다.

이 규칙에 대한 테스트는 CUSTOM-RULE-1과 동일하게 보이지만, 테스트 이름과 testing.evaluate_test_cases 함수에 전달된 처음 두 인수가 다를 것입니다:

rules/CUSTOM-RULE-2/main_test.rego

package rules

import data.lib
import data.lib.testing

test_CUSTOM_RULE_2 {
	# 규칙이 허용되는 테스트 케이스를 포함하는 배열
	allowed_test_cases := [{
		"want_msgs": [],
		"fixture": "allowed.tf",
	}]
    
	# 규칙이 거부되는 테스트 케이스를 포함하는 배열
	denied_test_cases := [{
		"want_msgs": ["input.resource.aws_redshift_cluster[denied].tags"],
		"fixture": "denied.tf",
	}]
	test_cases := array.concat(allowed_test_cases, denied_test_cases)
	testing.evaluate_test_cases("CUSTOM-RULE-2", "./rules/CUSTOM-RULE-2/fixtures", test_cases)
}

논리 OR (logical OR) 예시

OR 기능과 NOT 연산자를 결합하여 위 규칙을 다시 작성할 수도 있습니다.

새 규칙 CUSTOM-RULE-3에서 예시를 업데이트하여 다음 중 하나라도 실패하는 모든 경우를 거부합니다. 즉, 다음 중 하나가 누락된 모든 aws_redshift_cluster 리소스를 거부합니다:

1. "owner" 태그, OR

2. "description" 태그

이를 위해 각 경우에 대해 하나씩 두 개의 새 픽스처 파일을 사용합니다:

rules/CUSTOM-RULE-3/fixtures/denied1.tf

resource "aws_redshift_cluster" "denied1" {
  cluster_identifier = "tf-redshift-cluster"
  node_type          = "dc1.large"
  tags = {
    owner = "[email protected]"
  }
}

rules/CUSTOM-RULE-3/fixtures/denied2.tg

resource "aws_redshift_cluster" "denied2" {
  cluster_identifier = "tf-redshift-cluster"
  node_type          = "dc1.large"
  tags = {
    description = "description",
  }
}

Rego에서 논리 OR을 표현하려면 동일한 이름으로 여러 규칙 또는 함수를 정의하십시오. 이는 논리 OR에 대한 OPA 문서에도 설명되어 있습니다.

먼저 각 태그에 대한 NOT을 구현하는 함수를 추가합니다. 그런 다음 리소스를 사용하여 이 함수를 호출합니다:

rules/CUSTOM-RULE-3/main.rego

package rules

aws_redshift_cluster_tags_missing(resource) {
    not resource.tags.owner
}

aws_redshift_cluster_tags_missing(resource) {
    not resource.tags.description
}

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
    aws_redshift_cluster_tags_missing(resource)
    msg := {
        "publicId": "CUSTOM-RULE-3",
        "title": "태그에서 설명 또는 소유자 누락",
        "severity": "medium",
        "msg": sprintf("input.resource.aws_redshift_cluster[%s].tags", [name]),
        "issue": "",
        "impact": "",
        "remediation": "",
        "references": [],
    }
}

이렇게 하면 거부되는 모든 규칙이 성공적으로 반환됩니다.

Snyk은 단위 테스트 업데이트 및 실행을 통해 규칙이 올바른지 항상 확인하는 것을 권장합니다.

이 규칙에 대한 테스트는 이제 논리 OR이 예상대로 작동함을 보여주기 위해 여러 테스트 케이스를 포함할 것입니다:

rules/CUSTOM-RULE-3/main_test.rego

package rules

import data.lib
import data.lib.testing

test_CUSTOM_RULE_3 {
	# 규칙이 허용되는 테스트 케이스를 포함하는 배열
	allowed_test_cases := [{
		"want_msgs": [],
		"fixture": "allowed.tf",
	}]
    
	# 규칙이 거부되는 테스트 케이스를 포함하는 배열
	denied_test_cases := [{
		"want_msgs": ["input.resource.aws_redshift_cluster[denied1].tags"],
		"fixture": "denied1.tf",
	},{
		"want_msgs": ["input.resource.aws_redshift_cluster[denied2].tags"],
		"fixture": "denied2.tf",
	}]
	test_cases := array.concat(allowed_test_cases, denied_test_cases)
	testing.evaluate_test_cases("CUSTOM-RULE-3", "./rules/CUSTOM-RULE-3/fixtures", test_cases)
}

문자열 예시

이를 더욱 확장하여 세 번째 조건을 추가합니다. 다음 중 하나라도 누락된 모든 리소스를 거부합니다:

1. "owner" 태그, OR

2. "description" 태그, OR

3. 소유자의 이메일이 "@corp-domain.com" 도메인에 속하지 않음

rules/CUSTOM-RULE-4/main.rego

package rules

aws_redshift_cluster_tags_missing(resource) {
    not resource.tags.owner
}

aws_redshift_cluster_tags_missing(resource) {
    not resource.tags.description
}

aws_redshift_cluster_tags_missing(resource) {
    not endswith(resource.tags.owner, "@corp-domain.com")
}

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
    aws_redshift_cluster_tags_missing(resource)
    msg := {
        "publicId": "CUSTOM-RULE-4",
        "title": "태그에서 설명 및 소유자 누락 또는 소유자 태그가 이메일 요구 사항을 준수하지 않음",
        "severity": "medium",
        "msg": sprintf("input.resource.aws_redshift_cluster[%s].tags", [name]),
        "issue": "",
        "impact": "",
        "remediation": "",
        "references": [],
    }
}

Snyk은 단위 테스트 업데이트 및 실행을 통해 규칙이 올바른지 항상 확인하는 것을 권장합니다.

이 규칙에 대한 테스트는 이전 예시의 테스트와 매우 유사하게 보일 것이며 자체 픽스처 파일도 필요할 것입니다.

XOR 예시

이제 더 많은 복잡성을 추가하고 다음을 확인한다고 가정해 봅시다:

• 태그 유형이 "user"인 경우 "email" 태그도 존재합니다.

• 그렇지 않은 경우 다른 유형이 "service"라고 가정하면 serviceDescription이 있습니다.

• 이 두 가지는 상호 배타적입니다. 첫 번째 조건이 적용되면 두 번째 조건은 적용되지 않고 그 반대도 마찬가지입니다.

유형	이메일	ServiceDescription
사용자	예	아니요
서비스	아니요	예

이를 위해 checkTags 헬퍼 함수를 사용하도록 코드를 리팩토링할 수 있습니다. 이는 태그가 있는지 여부를 확인하고, OR과 함께 위의 두 가지 조건도 확인할 수 있습니다.

rules/CUSTOM-RULE-5/main.rego

package rules

checkTags(resource){
    resource.tags.type == "user"
    not resource.tags.email
}

checkTags(resource){
    resource.tags.type == "service"
    not resource.tags.serviceDescription
}

checkTags(resource){
    count(resource.tags) == 0
}

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
    checkTags(resource)   

    msg := {
        "publicId": "CUSTOM-RULE-5",
        "title": "복합 규칙",
        "severity": "medium",
        "msg": sprintf("input.resource.aws_redshift_cluster[%v].tags", [name]),
        "issue": "",
        "impact": "",
        "remediation": "",
        "references": [],
    }
}

이를 XOR로 변환하려면 else 규칙을 사용할 수 있습니다:

rules/CUSTOM-RULE-5/main.rego

package rules

checkUserTag(resource){
    not resource.tags.email
}

checkUserTag(resource){
    resource.tags.serviceDescription
}

checkServiceTag(resource){
    not resource.tags.serviceDescription
}

checkServiceTag(resource){
    resource.tags.email
}

checkTags(resource){
	count(resource.tags) == 0
}

checkTags(resource) {
    resource.tags.type == "user"
    checkUserTag(resource)
} else {
    resource.tags.type == "service"
    checkServiceTag(resource)
}

deny[msg] {
    resource := input.resource.aws_redshift_cluster[name]
	checkTags(resource)
    msg := {
        "publicId": "CUSTOM-RULE-5",
        "title": "사용자 또는 서비스 유형 리소스의 올바른 태그 누락",
        "severity": "medium",
        "msg": sprintf("input.resource.aws_redshift_cluster[%v].tags", [name]),
        "issue": "",
        "impact": "",
        "remediation": "",
        "references": [],
    }
}

직접 시도해 보려면 이 OPA Playground에서 동일한 예시를 사용하십시오.

Snyk은 단위 테스트 업데이트 및 실행을 통해 규칙이 올바른지 항상 확인하는 것을 권장합니다.

이 규칙에 대한 테스트는 이전 예시의 테스트와 매우 유사하게 보일 것이며 자체 픽스처 파일도 필요할 것입니다.

그룹화된 리소스 예시

리소스를 리소스 배열에 추가하여 많은 리소스를 반복할 수도 있습니다.

"resources": [
            "aws_iam_policy",
            "aws_iam_group_policy",
            "aws_iam_user_policy",
            "aws_iam_role_policy",
            "data.aws_iam_policy_document",
]

이를 활용하는 한 가지 방법은 거부 목록 규칙을 구현하는 것입니다.

예를 들어, Kubernetes ConfigMap을 정의하는 경우 암호, 비밀 키, 액세스 토큰과 같은 민감한 정보를 저장하는 데 사용할 수 없도록 해야 합니다.

다음과 같이 거부 목록에 민감한 토큰 그룹을 정의하여 이를 수행하고 "민감한 정보"로 정의된 내용을 시간이 지남에 따라 확장할 수 있습니다:

package rules

sensitive_denylist := [
	"pass",
	"secret",
	"key",
	"token",
]

check_sensitive(keys, denylist) {
	_ = keys[key]
	contains(key, denylist[_])
}

deny[msg] {
	input.kind == "ConfigMap"
	input.data = keys
	check_sensitive(keys, sensitive_denylist)
	msg := {
		"publicId": "CUSTOM-RULE-7",
		"title": "ConfigMap이 민감한 데이터를 노출합니다.",
		"severity": "high",
		"msg": "input.data",
		"issue": "",
		"impact": "",
		"remediation": "",
		"references": [],
	}
}

"pass", "secret", "key", "token" 부분 문자열을 포함하는 모든 키는 민감한 것으로 간주될 수 있으므로 ConfigMap에 포함되어서는 안 됩니다.