OPA Gatekeeper 와 Kyverno

OPA(Open Policy Agent)

https://www.openpolicyagent.org/

Open Policy Agent

 

 

1. 오픈 소스 범용 정책 엔진
2. Kubernetes 에 정책을 적용하는 것 뿐만 아니라 더 넓은 사용 사례를 가지고 있음
3. Kubernetes 는 OPA 를 통합/적용할 수 있는 대상 중 하나(with Gatekeeper)
4. OPA 에서는 Rego 라는 자체적인 쿼리 언어를 사용

 

 

OPA Gatekeeper

https://open-policy-agent.github.io/gatekeeper/website/docs/

Introduction | Gatekeeper

 

1. OPA 와 kubernetes 를 통합하기 위한 프로젝트
2. constraints/constraint templates 과 같은 CRD 를 이용하여 정책을 인스턴스화
3. 다양한 정책 샘플 제공

 

 

OPA Gatekeeper 배포

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper gatekeeper/gatekeeper --namespace gatekeeper-system --create-namespace

 

 

OPA Gatekeeper 정책 예제

아래는 특정 레이블이 존재하는지 검증하는 정책 템플릿을 만들고, 해당 템플릿을 사용하여 정책을 만드는 샘플

 

Step 1. ConstraintTemplate

리소스의 레이블을 검증하는 ConstraintTemplate(k8srequiredlabels)을 생성

 

# k8srequiredlabels_template.yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }

 

 

Step 2. Constraints

네임스페이스를 생성할 때 “gatekeeper”라는 키를 가지는 레이블이 존재하는지 검증하는 정책(ns-must-have-gk)을 생성

 

# all_ns_must_have_gatekeeper.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-gk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["gatekeeper"] # 체크할 레이블의 키

 

 

Step 3. 검증

“gatekeeper” 레이블이 없는 경우

$ kubectl apply -f bad/bad_ns.yaml
Error from server (Forbidden): error when creating "bad/bad_ns.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [ns-must-have-gk] you must provide labels: {"gatekeeper"}

 

“gatekeeper” 레이블이 있는 경우

# good_ns.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: good-ns
  labels:
    gatekeeper: "true"

$ kubectl apply -f good/good_ns.yaml
namespace/good-ns created

 

그 외에도 다양한 정책 샘플을 제공하기 때문에 샘플을 그대로 사용해도 되지만, 샘플을 응용하여 자신의 환경에 맞는 커스텀 정책을 생성할 수도 있다.

https://github.com/open-policy-agent/gatekeeper-library/tree/master/library

gatekeeper-library/library at master · open-policy-agent/gatekeeper-library

 

 

 

Kyverno

https://kyverno.io/

Kyverno

https://kyverno.io/policies/

Policies

 

 

Kyverno 프로젝트는 Kubernetes 및 기타 클라우드 네이티브 환경에 대한 전체 Policy-as-Code(PaC) 수명 주기를 관리하기 위한 포괄적인 도구

 

 

Kyverno 배포

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

 

 

Kyverno 의 세 가지 주요 기능(검증, 변형, 생성)

 

1. 리소스 검증

리소스 생성 요청 시 리소스가 정책에 부합하는지 검증

(기본적으로 kube-system 네임스페이스와 kyverno 네임스페이스는 검증 대상에서 제외됨)

 

# cpol-require-labels.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  rules:
  - name: check-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      failureAction: Enforce
      message: "label 'team' is required"
      pattern:
        metadata:
          labels:
            team: "?*"

 

레이블이 없는 파드 생성 시

$ kubectl create deployment nginx --image=nginx -n default
error: failed to create deployment: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Deployment/default/nginx was blocked due to the following policies

require-labels:
  autogen-check-team: 'validation error: label ''team'' is required. rule autogen-check-team
    failed at path /spec/template/metadata/labels/team/'

 

 

2. 리소스 변형

검증과 유사하지만 검증 후 정책에 따라 리소스를 배포 전 변형하는 기능

 

# cpol-add-labels.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-labels
spec:
  rules:
  - name: add-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            +(team): bravo # team 레이블이 없는 경우 team=bravo 라는 레이블을 추가

 

 

3. 리소스 생성

정책에 따라 새로운 리소스를 생성할 수도 있기 때문에 강력한 자동화 기능

아래는 모든 네임스페이스(kube-system, kyverno 제외)에 NetworkPolicy 를 생성하는 예제

 

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-resources
spec:
  rules:
  - name: generate-existing-networkpolicy
    match:
      any:
      - resources:
          kinds:
          - Namespace
    generate:
      generateExisting: true # 정책이 존재하기 이전에 생성된 리소스에도 리소스를 생성할지 여부를 정의함(기본값 false)
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      name: default-deny
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      data:
        metadata:
          labels:
            created-by: kyverno
        spec:
          podSelector: {}
          policyTypes:
          - Ingress
          - Egress

 

리소스 생성 시 리소스 종류에 따라 필요한 권한에 대한 추가 역할 정의가 필요할 수도 있음(aggregated-clusterroles 사용)

https://kyverno.io/docs/installation/customization/#customizing-permissions

Configuring Kyverno

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles

Using RBAC Authorization

 

# 만약 generate 구문 속의 생성할 리소스가 Secret 인 경우 추가 권한 부여 필요
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kyverno:secrets:view
  labels:
    rbac.kyverno.io/aggregate-to-admission-controller: "true"
    rbac.kyverno.io/aggregate-to-reports-controller: "true"
    rbac.kyverno.io/aggregate-to-background-controller: "true"
rules:
- apiGroups:
  - ''
  resources:
  - secrets
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kyverno:secrets:manage
  labels:
    rbac.kyverno.io/aggregate-to-background-controller: "true"
rules:
- apiGroups:
  - ''
  resources:
  - secrets
  verbs:
  - create
  - update
  - delete

 

 

 

OPA 와 Kyverno 를 비교

 

OPA

1. 범용 정책 엔진 - Kubernetes 뿐 아니라 다양한 사례에서 사용할 수 있다.
2. Rego 언어 - 정책을 정의하기 위해 특수 정책 언어인 Rego 를 사용한다.
3. 유연성 - 더욱 다양한 정책 시행 시나리오에 사용할 수 있다.
4. 성숙한 프로젝트 - OPA 는 CNCF Graduated 프로젝트이다.(Kyverno 는 CNCF Incubating 프로젝트)

 

 

Kyverno

1. Kubernetes native - 주로 Kubernetes 정책 시행을 위해 설계되었으며, Kubernetes 와 직접 통합되므로 Kubernetes 객체로 정책을 관리하기가 더 쉽다.
2. YAML 기반 정책 - Kubernetes 리소스를 정의하는 데 사용되는 언어와 동일한 YAML을 사용하여 정책 생성을 간소화한다.
3. 간소화된 정책 언어 - Rego 와 같은 새로운 정책 언어를 배울 필요가 없다.

 

 

주요 차이점

1. 정책 언어 - Kyverno 는 yaml 을 사용하는 반면, OPA 는 Rego 를 사용한다.
2. Kubernetes 통합 - Kyverno 는 OPA 보다 Kubernetes 와 더 긴밀하게 통합되어 있다.
3. 사용 범위 - Kyverno 는 Kubernetes 에 중점을 두고 있는 반면, OPA 는 더 넓은 사용 사례를 가진다.
4. 복잡성 - Kyverno 는 OPA 에 비해 상대적으로 Kubernetes 관리자가 배우고 사용하기 쉽다.
5. 변형 및 생성 - Kyverno 는 Kubernetes 리소스 변형 및 생성을 지원하는 반면 OPA 의 변형 지원은 더 제한적이다.

 

 

요약

1. Kubernetes 정책 시행에 주로 중점을 두고 YAML 기반 정책을 적용한 간단한 Kubernetes native 솔루션을 원하는 경우 Kyverno 를 선택
2. 보다 넓은 사용 사례를 가진 정책 엔진이 필요하고, Rego 에 대한 깊은 이해가 있다면 OPA 를 선택