OPA Gatekeeper 퀴즈

마지막 업데이트: 2026년 9월 13일

다음 질문들을 통해 OPA Gatekeeper와 Rego 정책 언어에 대한 이해도를 점검해보세요.

---

문제

1. OPA Gatekeeper에서 정책을 작성하는 데 사용되는 언어는?

• A) YAML
• B) JSON
• C) Rego
• D) HCL

정답 보기

정답: C) Rego

설명: OPA(Open Policy Agent)는 Rego라는 선언적 정책 언어를 사용합니다. Rego는 JSON/YAML 데이터를 쿼리하고 정책 결정을 내리는 데 최적화되어 있습니다.

package docsrequiredlabels
valid_label(key) if {
  value := input.review.object.metadata.labels[key]
  is_string(value)
  value != ""
}
violation contains {"msg": sprintf("required nonempty label: %v", [key])} if {
  some key in input.parameters.labels
  not valid_label(key)
}

Rego의 집합·comprehension·JSON 입력 계약을 익히고 실제 요구와 테스트에 맞춰 정책 도구를 선택합니다.

---

2. Gatekeeper에서 재사용 가능한 정책 템플릿을 정의하는 CRD는?

• A) Policy
• B) ConstraintTemplate
• C) PolicyTemplate
• D) GatekeeperPolicy

정답 보기

정답: B) ConstraintTemplate

설명: ConstraintTemplate은 Rego 정책 로직과 파라미터 스키마를 정의합니다:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: docsrequiredlabels
spec:
  crd:
    spec:
      names:
        kind: DocsRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              minItems: 1
              items:
                type: string
                minLength: 1
          required:
          - labels
  targets:
  - target: admission.k8s.gatekeeper.sh
    code:
    - engine: Rego
      source:
        version: v1
        rego: |
          package docsrequiredlabels
          valid_label(key) if {
            value := input.review.object.metadata.labels[key]
            is_string(value)
            value != ""
          }
          violation contains {"msg": sprintf("required nonempty label: %v", [key])} if {
            some key in input.parameters.labels
            not valid_label(key)
          }

ConstraintTemplate을 기반으로 Constraint를 생성하여 실제 정책을 적용합니다.

---

3. Gatekeeper Constraint의 enforcementAction 필드에서 지원하지 않는 값은?

• A) deny
• B) dryrun
• C) warn
• D) audit

정답 보기

정답: D) audit

설명: Gatekeeper의 enforcementAction 지원 값:

• deny: 정책 위반 시 요청 거부
• dryrun: 위반을 기록하지만 요청은 허용
• warn: 경고 메시지 표시, 요청은 허용

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: DocsRequiredLabels
metadata:
  name: required-labels
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ''
      kinds:
      - Pod
    namespaces:
    - policy-lab
  parameters:
    labels:
    - app.kubernetes.io/name

audit은 enforcementAction이 아니라 Gatekeeper의 백그라운드 감사 기능입니다.

---

4. Rego에서 배열의 모든 요소를 순회하는 구문은?

• A) for item in array
• B) array.forEach(item)
• C) item := array[_]
• D) loop array as item

정답 보기

정답: C) item := array[_]

설명: Rego에서 [_]는 배열의 모든 인덱스를 의미합니다:

# 모든 컨테이너 순회
container := input.review.object.spec.containers[_]

# 모든 레이블 키 순회
key := object.keys(input.review.object.metadata.labels)[_]

# 특정 인덱스
first_container := input.review.object.spec.containers[0]

# 인덱스와 값 모두 필요할 때
some i
container := input.review.object.spec.containers[i]

이 구문은 Rego의 핵심 패턴으로, 규칙 내에서 여러 값을 평가할 때 사용됩니다.

---

5. Gatekeeper에서 기존 클러스터 리소스의 정책 준수 여부를 확인하는 기능은?

• A) Validation
• B) Mutation
• C) Audit
• D) Generation

정답 보기

정답: C) Audit

설명: Gatekeeper Audit 기능:

• 주기적으로 기존 리소스 검사
• Constraint status에 위반 사항 기록
• 새 리소스뿐만 아니라 기존 리소스도 검증

# Constraint의 위반 사항 확인
kubectl describe docsrequiredlabels required-labels

# Status 섹션에서 위반 확인:
# Status:
#   Audit Timestamp: 2026-02-21T10:00:00Z
#   Total Violations: 3
#   Violations:
#     - Kind: Pod
#       Name: nginx-without-labels
#       Namespace: default

이를 통해 정책 적용 전 영향을 파악할 수 있습니다.

---

6. Gatekeeper 3.23.1에서 지원하는 리소스 자동 수정 기능의 CRD는?

• A) MutatingPolicy
• B) Assign / AssignMetadata
• C) ModifyResource
• D) ResourceMutator

정답 보기

정답: B) Assign / AssignMetadata

설명: Gatekeeper의 Mutation CRD:

• AssignMetadata: 메타데이터(레이블, 어노테이션) 추가
• Assign: spec 필드 등 일반 필드 수정
• ModifySet: 배열에 값 추가/제거

apiVersion: mutations.gatekeeper.sh/v1
kind: AssignMetadata
metadata:
  name: add-owner-label
spec:
  match:
    scope: Namespaced
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  location: "metadata.labels.owner"
  parameters:
    assign:
      value: "platform-team"

Kyverno의 mutate와 유사한 기능입니다.

---

7. Rego에서 두 집합의 차이를 계산하는 연산자는?

• A) difference()
• B) subtract()
• C) - (마이너스)
• D) diff()

정답 보기

정답: C) - (마이너스)

설명: Rego의 집합 연산:

# 필요한 레이블과 존재하는 레이블 비교
required := {"app", "env", "team"}
provided := {"app", "team"}

# 차집합: 없는 레이블 찾기
missing := required - provided
# 결과: {"env"}

# 교집합
common := required & provided
# 결과: {"app", "team"}

# 합집합
all := required | provided

이 연산은 필수 레이블 검증 등에 자주 사용됩니다.

---

8. Gatekeeper에서 다른 네임스페이스의 리소스를 참조하기 위해 필요한 설정은?

• A) CrossNamespacePolicy
• B) Config의 sync.syncOnly
• C) GlobalConstraint
• D) NamespaceSelector

정답 보기

정답: B) Config의 sync.syncOnly

설명: 이 예제는 Kubernetes 객체를 inventory로 동기화합니다. 외부 HTTP provider나 임의 bundle 자동 연동과는 다릅니다:

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: gatekeeper-system
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: "networking.k8s.io"
        version: "v1"
        kind: "Ingress"

동기화된 리소스는 Rego에서 data.inventory로 접근할 수 있습니다:

other_ingress := data.inventory.namespace[ns]["networking.k8s.io/v1"]["Ingress"][name]

---

9. Gatekeeper 정책 테스트를 위한 공식 CLI 도구는?

• A) opa test
• B) gatekeeper-cli
• C) gator
• D) conftest

정답 보기

정답: C) gator

설명: Gator는 Gatekeeper 정책을 로컬에서 테스트하는 공식 CLI 도구입니다:

# 설치
gator version  # verified 3.23.1 release binary

# 정책 검증
gator verify tests/suite.yaml --verbose

# 테스트 스위트 실행
gator test -f templates/ -f constraints/ -f tests/fixtures/labels-present.yaml --output=json

테스트 스위트 예시:

apiVersion: test.gatekeeper.sh/v1alpha1
kind: Suite
metadata:
  name: docs-gatekeeper
tests:
- name: required-labels
  template: ../templates/docsrequiredlabels.yaml
  constraint: ../constraints/required-labels.yaml
  cases:
  - name: labels-present
    object: fixtures/labels-present.yaml
    assertions:
    - violations: 0
  - name: labels-absent
    object: fixtures/labels-absent.yaml
    assertions:
    - violations: 1

---

10. Rego 정책을 선택할 구체적인 요구 사례는?

• A) 어떤 정책이든 더 적은 메모리가 보장되어야 한다
• B) 모든 리소스를 검사 없이 자동 생성해야 한다
• C) 다른 엔진보다 항상 복잡한 로직을 처리해야 한다
• D) JSON 입력에 집합 연산과 comprehension을 적용하고 테스트로 검증하려 한다

정답 보기

정답: D) JSON 입력에 집합 연산과 comprehension을 적용하고 테스트로 검증하려 한다

설명: Rego는 이 요구에 맞는 선언적 연산을 제공합니다. 특정 정책의 표현 방식, 팀의 숙련도, 테스트, 운영 요구를 비교해야 하며 Gatekeeper가 항상 더 빠르거나 더 복잡한 정책을 표현한다고 일반화하지 않습니다.

---

11. Rego에서 violation 규칙이 여러 개 정의되어 있을 때 평가 방식은?

• A) 첫 번째 규칙만 평가
• B) 모든 규칙을 OR로 평가
• C) 모든 규칙을 AND로 평가
• D) 랜덤하게 하나 선택

정답 보기

정답: B) 모든 규칙을 OR로 평가

설명: 같은 partial-set violation rule의 여러 정의는 각각의 결과를 집합에 추가합니다:

package examples
violation contains {"msg": "Privileged container"} if {
  container := input.review.object.spec.containers[_]
  container.securityContext.privileged == true
}
violation contains {"msg": "Explicit root user"} if {
  container := input.review.object.spec.containers[_]
  container.securityContext.runAsUser == 0
}

각 violation 규칙의 결과는 집합에 추가되며, 하나 이상의 위반이 있으면 전체 정책이 실패합니다.

같은 partial-set violation rule의 결과를 합칩니다. 각 본문의 조건은 AND이며 complete-document rule의 충돌까지 OR로 해결하지는 않습니다. 이 조각은 전체 PSS 구현이 아닙니다.

---

12. Gatekeeper에서 Constraint가 특정 네임스페이스에만 적용되도록 설정하는 필드는?

• A) spec.targetNamespaces
• B) spec.match.namespaces
• C) spec.scope.namespaces
• D) spec.selector.namespaces

정답 보기

정답: B) spec.match.namespaces

설명: Constraint의 match 섹션에서 적용 범위를 지정합니다:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: DocsRequiredLabels
metadata:
  name: required-labels
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ''
      kinds:
      - Pod
    namespaces:
    - production
    - staging
  parameters:
    labels:
    - app.kubernetes.io/name

• namespaces: 포함할 네임스페이스 목록
• excludedNamespaces: 제외할 네임스페이스 목록
• namespaceSelector: 레이블 기반 선택

---

점수 계산

각 문제당 1점으로 계산합니다.

점수	평가
11-12	우수 - OPA Gatekeeper 전문가 수준
8-10	양호 - 기본 개념 이해, Rego 심화 학습 필요
5-7	보통 - 추가 학습 권장
0-4	기초 학습 필요

---

관련 문서

• OPA Gatekeeper
• Kyverno 정책 관리
• Pod Security Standards