쿠버네티스 Admission Control #2 - Open Policy Agent | 커피고래의 노트

[utterances-bot]

쿠버네티스 Admission Control #2 - Open Policy Agent | 커피고래의 노트

지난 쿠버네티스 Admission Control #1에서는 Admission Control의 개념에 대해 알아보았고 직접 Custom Admission Controller을 만들어 봤습니다. 이번 시간에는 General Policy Controller인 Open Policy Agent(OPA)에 대해서 알아보고 OPA Policy를 이용하여 사용자의 세부 사용성을 관리해 보겠습니다.

https://coffeewhale.com/kubernetes/admission-control/2021/05/04/opa2/

[jihwahn1018]

좋은 글 감사합니다! 혹시 특정 namespace들에 default가 아닌 저희가 구성한 service account를 지정하도록 해주는 mutating admission webhook도 OPA를 통해 구현가능할까요?

예시들을 찾아보니 주로 mutating 보다는 validation 쪽 부분이 많아서 질문드립니다.

[hongkunyoo]

안녕하세요, @jihwahn1018 님 네 OPA로 mutating도 가능합니다. 여기 쓰레드를 한번 참고해 보시기 바랍니다. https://github.com/open-policy-agent/opa/issues/943

[YeonSeoMom]

mutating을 사용할만한 건 gatekeeper 예제코드를 보는 것도 좋을듯 합니다. https://github.com/open-policy-agent/gatekeeper-library

[hongkunyoo]

@YeonSeoMom 안녕하세요. 좋은 정보 감사합니다!

[IMyoungho]

안녕하세요ㅎㅎ 커피고래님! 항상 좋은글 감사드립니다:)

Webhook과 OPA의 차이에 대한 질문이 있어서 글 남깁니다!

제가 이해하기로는 webhook의 경우는 사용자가 접근관리에 대해 로직을 만들고 webhook 서버를 docker 이미지로 빌드한 뒤에 그걸 쿠버네티스에 올려서 사용하는 방식이라 수정이 필요할 때마다 이를 재빌드해서 앞의 과정을 반복하는 번거로움이 있다는 점이 특징이고

OPA의 경우는 policy에 대한 내용을 rego 스크립트를 이용해서 수정이 필요할 때 webhook의 재빌드와 같은 과정이 없기 때문에 즉각 수정하면 되어서 관리 및 운영이 편하다 라는 차이로 이해하면 될까요??

결과적으로 둘다 결국엔 직접동작하는 것이 아닌 admission controller에게 결과만 전달한다는 것이 공통점인고 하는 일은 거의 흡사하지만 OPA가 편리를 위해 만들어진 툴이라고 이해하면 될까요??

[hongkunyoo]

안녕하세요, @IMyoungho 님 네, 말씀하신 부분에 대해서 저도 그렇게 생각합니다. 직접 webhook으로 로직을 작성하든, OPA를 이용하든 결국은 Admission Controller를 통해 validation이 이루어 집니다. 제기 생각하는 OPA의 의미는,

초기 학습비용이 조금 있긴 하지만 어느 정도 숙달이 되고 나면 선언적으로(declarative) 손쉽게 validation 로직을 구현할 수 있고 말씀하신 것처럼 재빌드 과정 없이 바로 적용할 수 있다.

라고 생각합니다. Admisssion control을 반드시 OPA를 통해서 할 필요는 없으며 여러 툴 중에 편리하게 사용할 수 있는 종류라고 생각합니다.

[IMyoungho]

@hongkunyoo 감사합니다:)