OPA 와 OPA Gatekeeper

OPA?

 

모든 조직에는 '정책'이라는 것이 있습니다. 어떤 정책은 거버넌스, 법적 요구사항 때문에 반드시 지켜야 하는 것이라면, 어떤 정책은 아키텍처적인 베스트 프랙티스를 유지하고 조직의 운영 컨벤션(convention) 때문에 필요하기도 합니다. 이런 요건들을 수작업으로 관리하면 휴먼 에러도 발생할 수 있고 무엇보다도 굉장히 따분하고 짜증나는 일입니다. 때때로는 이런 정책을 지키는 것 때문에 어플리케이션 개발의 속도가 늦어진다든지 하는 일이 발생하기도 해서, 정책과 컴플라이언스를 유지하는 것이 소위 말하는 agility와 함께 가기 어려운 것으로 느껴졌습니다.

OPA는 정책을 통합하여 적용/관리하도록 도와주는 오픈소스 프로젝트입니다. 컴플라이언스 정책을 선언적(declarative) 언어를 이용해 코드로 정의할 수 있게 해줍니다. 또한 간단한 API를 통해 컴플라이언스 관리 정책 정의를 어플리케이션과 k8s 플랫폼으로부터 독립적으로 가져갈 수 있게 해줍니다. 보통 마이크로서비스, 쿠버네티스 환경, CI/CD 파이프라인, API Gateway 등에서 활용되고 있습니다.

 

왜 OPA를 써야 할까?

클라우드 네이티브 생태계를 보면 너무 많은 오픈소스 프로젝트들이 새로 생겨나고 사라집니다. 그리고 그네들 자체적으로 인증과 정책을 갖게 되는데, 이로 인해 전체적인 보안 상태를 점검하고 위협/취약점 통제를 하기가 어려워집니다. 옛날부터 있어왔던 접근 제어, 정책 반영 소프트웨어 등은 모던 어플리케이션을 기준으로 만들어 지지 않았기 때문에, 과거에 비해 훨씬 더 동적이고 호출이 많은 어플리케이션들을 감당하기 어렵게 되었습니다. 

OPA는 이런 문제를 해결하기 위한 프로젝트 입니다. 어떤 정책을 팀 내 위키에 올리고 등등을 통해 관리하는 게 아니라, 하나의 정책 엔진을 사용해서 다른 많은 제품들과 통합하여 사용할 수 있도록 하게 해주는 것입니다.

OPA 정책 정의

Rego라는 언어를 사용해서 정책을 정의하게 되는데, 이를 조금 더 쉽게 정의할 수 있게 도와주는 Playground 툴이 있습니다. 여기에서 정의를 하게 되면 내가 작성한 Rego 정책에 대해, 어떤 인풋이 들어왔을 때 어떤 액션이 취해질 것인지를 확인할 수 있습니다.

위 스크린샷은 특정 IP 대역에서 들어온 접근 시도에 대해서만 허용하는 정책 예시입니다. 테스트 Input을 지정하고 Evaluate 를 클릭하면 Output에 결과가 뜨는 구조입니다.

 

OPA Gatekeeper

아래 내용은 Gatekeeper v3.0을 기준으로 작성되었습니다.

쿠버네티스에서는 이런 정책적인 결정을 API 서버와 분리해서 독립적으로 할 수 있도록 하기 위해 admission controller webhooks을 제공하는데, 이는 하나의 자원이 생성, 업데이트, 삭제될 때 무조건 실행되게 됩니다. 게이트키퍼는 이 웹훅을 확인해서 OPA 정책 엔진에서 정의한 대로 특정 액션을 취해줍니다.

• 참고: Gatekeeper 가 OPA랑 어떻게 다른가?
  • 파라미터 등을 사용할 수 있는 보다 유연하고 다양한 정책 라이브러리
  • 정책 라이브러리 instantiate을 위한 쿠버네티스 네이티브 커스텀 리소스 (constraints)
  • 정책 라이브러리 확장을 위한 쿠버네티스 네이티브 커스텀 리소스 (contraint templates)
  • 감사 기능

주요 기능

예를 들어서 여러분의 조직이 모든 K8S 오브젝트에 어느 부서가 담당하는지 알 수 있도록 label 값을 갖게 하고 싶다고 가정하고, OPA Gatekeeper의 주요 기능을 한 번 살펴봅시다.

Validating Admission control

모든 Gatekeeper 컴포넌트가 클러스터에 설치되고 나면, API 서버가 Gatekeeper admission webhook을 트리거 해서 자원 생성/삭제/업데이트를 검사합니다. 검증 과정에서 Gatekeeper 가 API 서버와 OPA 사이에서 다리 역할을 해줍니다. 다시 말해, OPA가 정의하는 정책들을 API 서버가 적용해주는 거죠. 뭐를 통해서? OPA Gateway를 통해서.

Policies and Constraints

OPA Constraint Framework 와 함께, Constraint라는 것은 정책 작성자가 정의한 요구사항을 한 시스템이 반드시 따라야 한다는 것을 의미합니다. 각 Constraint는 Rego 라는 언어로 작성이 되고, 시스템의 이상적인 기대 상태를 위반하는 리소스들을 확인하는 데에 사용됩니다.

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-hr
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Namespace"]
      parameters:
        labels: ["hr"]

Audit

감사 기능은 배포된 자원들을 정기적으로 감시해서 Constraints 내용에 반하는 것이 있는지 확인하여 조치합니다. Gatekeeper 에서 감사 결과를 따로 저장합니다. 아래와 같이 status에서 언제 감사가 이루어졌는지, violations는 어떤 것이 있었고 어떻게 조치되었는지 결과를 볼 수 있습니다.

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-hr
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Namespace"]
      parameters:
        labels: ["hr"]
    status:
      auditTimestamp: "2019-08-06T01:46:13Z"
      byPod:
      - enforced: true
        id: gatekeeper-controller-manager-0
      violations:
      - enforcementAction: deny
        kind: Namespace
        message: 'you must provide labels: {"hr"}'
        name: default
      - enforcementAction: deny
        kind: Namespace
        message: 'you must provide labels: {"hr"}'
        name: gatekeeper-system
      - enforcementAction: deny
        kind: Namespace
        message: 'you must provide labels: {"hr"}'
        name: kube-public
      - enforcementAction: deny
        kind: Namespace
        message: 'you must provide labels: {"hr"}'
        name: kube-system

Data Replication

감사가 이루어질 때는 K8S 자원에 바로 하는 것이 아니라, 그 자원을 복제해서 수행합니다. 그래서 Constraint 에는 데이터 복제를 할 수 있도록 하는 권한이 잘 부여되어 있어야 합니다. 이를 위해서는 아래처럼 config 자원을 생성해주어야 합니다. 아래 예시는 모든 네임스페이스와 파드를 OPA로 복제할 수 있게 해주는 Config 오브젝트입니다.

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

 

 

알아두면 좋은 도구들

Kubernetes 에서 자주 쓰이는 PodSecurityPolicy with OPA 정책 예제

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

도구는 아니고 Gatekeeper에 붙어 있는 Policy 저장소?인데, 고려해봐야 하는 포인트들을 리스트업 하고 샘플 Constraint 를 제공합니다. 아래 레파지토리의 내용들은 Pod Security Policy 오브젝트로 지정될 법한 것들을 어플리케이션과 분리하여 OPA로 쓸 때 좋은 것들이라고 이해하면 좋겠습니다.
https://github.com/open-policy-agent/gatekeeper/tree/master/library/pod-security-policy

• PodSecurityPolicy: 파드가 실행될 때 반드시 지켜야 하는 것들을 정의. 이 조건이 만족되지 않으면 생성이 되지 않음.

Gateway Policy Manager (GPM)

이렇게 정책을 관리하는 것이 쉽지 않다. 현재 정의된 Constraint (구 Constraint Template) 내용과 현재 status, violation 등을 확인할 수 있게 해주는 읽기 전용 대시보드.