어플리케이션 라이프사이클에 따른 OPA 정책 적용

이 포스트는 Kubecon의 Applying Policy Throughout The Application Lifecycle with Open Policy Agent 세션을 듣고 작성하였음을 밝힙니다.

내 어플리케이션이 정책을 따라가게 하려면?

정책이란, 이 환경에서 할 수 있는 것과 해서는 안되는 것을 정의하는 일이다. 예를 들어 우리 환경에서는 Go를 1.13 버전 이상으로만 사용해야 한다 같은 것이 정책이다. 이 정책을 여러 클라우드 네이티브 솔루션들에 걸쳐, 하나의 통합된 방식으로 유연하게 정의하고 적용할 수 있게 해주는 것이 OPA 이다. 그렇다면 이 OPA 정책을 어디에서 적용할 것인가 이야기해보기 위해 어플리케이션의 라이프사이클을 세 단계로 나누고 시작하려고 한다.

출처: https://youtu.be/cXfsaE6RKfc

1. Local Development
   개발자들이 코드를 작성하는 과정. 여기에서는 Code convention, 내부 정책 등등의 방식을 통해 개발자 개인이 해당 정책을 반영시킨다. 이 단계에서는 사실상 무엇이든 시도할 수 있기 때문에 정책의 적용이 가장 빠른 단계라고 볼 수 있다. 그렇지만 사람이 하는 일이니 모든 정책이 정확히 반영될 것이라고 확언하기는 어렵다. 그래서 잘 만든 정책을 개발자들이 쉽게 적용할 수 있도록 하는 것이 핵심 과제이다.

2. Continuous Integration
   개발자가 코드를 커밋한 뒤 완성된 아티팩트를 만드는 CI 단계. Unit test 등등의 과정을 거쳐 정상 동작하는 코드를 만든다. 이 과정에서 정책 준수 여부를 확인하는 방식을 CI의 한 단계로 파이프라인에 추가할 수 있다. 이렇게 하면 개발자들에게 해당 정책 반영 여부가 빠르게 전달된다.

3. Production
   Continuous Delivery 까지 완료되어 실제 서비스를 하고 있는 환경. 어떤 변경이 반영되는 것이 가장 어려운 환경이다. 애초에 정책 위반되는 애들이 들어오지 못하도록 가드레일을 확실히 해주어야 한다. 그리고 문제가 생기는 애들이 있으면 기록을 남겨두어야 한다.

Conftest

Conftest는 OPA를 기반으로 만들어진 테스팅 툴이다. 개발자들이 익숙한 방식으로, 지금 배포하려고 하는 코드가 회사의 중앙 정책과 위배되지는 않는지 혹은 지금 배포하려는 정책이 예상한 테스트 케이스를 정확히 통과하는지 확인할 수 있게 해준다.

아래는 Conftest 의 사용 예시 중 Docker 부분을 차용하여 Conftest 를 어떻게 사용하는지 설명한다.

1. Rego 정의

   package commands
   
   denylist = [
     "apk",
     "apt",
     "pip",
     "curl",
     "wget",
   ]
   
   deny[msg] {
     input[i].Cmd == "run"
     val := input[i].Value
     contains(val[_], denylist[_])
   
     msg = sprintf("unallowed commands found %s", [val])
   }

2. 대상 인풋 정의

   FROM openjdk:8-jdk-alpine
   VOLUME /tmp  
   ARG DEPENDENCY=target/dependency  
   COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib  
   COPY ${DEPENDENCY}/META-INF /app/META-INF  
   COPY ${DEPENDENCY}/BOOT-INF/classes /app
   
   RUN apk add --no-cache python3 python3-dev build-base && pip3 install awscli==1.18.1
   
   ENTRYPOINT \["java","-cp","app:app/lib/\*","hello.Application"\]
   

3. conftest test XX 수행
   1번에서 정의한 정책이 policy 라는 폴더 아래에 위치하고, 그 바로 상위 폴더에서 conftest 를 수행하면 아래와 같은 결과를 볼 수 있다.

이런 방식으로 생성하는 K8S Manifest, Dockerfile 에 대해 linting 하는 것처럼 작성하는 과정에서 바로 위반하고 있는 정책은 없는지 확인할 수 있다. conftest 를 통해 위에서 살펴본 개발, CI 단계에서의 정책 적용을 할 수 있을 것 같다.

 

Gatekeeper

이전 포스팅에서 살펴본 OPA Gatekeeper 가 프로덕션 환경에서 정책 위반 오브젝트들을 k8s 환경에 들어오지 못하도록 해주는 가드레일 역할을 해준다. 위 kubecon 발표에서 인상적이었던 점은, 개인적으로 해결하고 싶었던 OPA 정책(rego) 과 ContraintTemplate 간의 결합 부분이었다. ConstraintTemplate 은 Rego 를 안에 품고 있어야 하는 구조라서, OPA의 장점인 유연성과 확장성을 충분히 활용하지 못하는 건 아닐까 하는 걱정이 됐기 때문이다.

발표를 듣고 생각해본 Rego -> ConstraintTemplate 으로 이어지는 배포 구조는 아래와 같다.

1. Policykit
   Rego 정책을 ConstraintTemplate 으로 패킹해준다.

2. Conftest
   생성하려는 yaml을 테스트 했던 것을 역으로 활용해서, 정책의 테스트케이스를 만들어서 테스트를 수행한다.

3. GitOps 툴킷을 사용하여 Kubernetes cluster에 배포

점차 OPA 가 정책 엔진 표준으로 자리 잡아 가면서 OPA 정책을 더 잘 쓰고 더 빠르게 적용시킬 수 있는 툴들이 많이 나오고 있는 것으로 보인다.