개발자 / 보안 / 클라우드

클라우드 네이티브 환경을 위한 범용 정책 엔진 OPA의 이해

Tim Hinrichs | InfoWorld 2020.08.10
조직이 클라우드를 도입하면 클라우드 네이티브 스택의 역동성과 규모로 인해 훨씬 더 복잡한 보안과 컴플라이언스 환경이 필요하게 된다. 예를 들어 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 사용이 늘면 개발자와 데브옵스팀은 컴퓨팅, 스토리지, 네트워킹과 같은 전통적인 영역과 함께 승인 제어와 같은 정책 영역에 대한 새로운 책임도 맡게 된다. 또한 각 애플리케이션과 마이크로서비스 또는 서비스 메시에 각각의 권한 부여 정책이 필요한데, 개발자들이 난관을 겪는 부분이다.
 
ⓒ Getty Images Bank

이러한 이유로 조직은 클라우드에서 정책을 만들고 시행하고 관리할 더 간단하고 시간 효율적인 방법을 찾는다. 개방형 정책 에이전트(Open Policy Agent, OPA)의 역할이 그것이다. 4년전 오픈소스로 만들어진 도메인 중립적 정책 엔진인 OPA는 현재 클라우드 네이티브 정책의 사실상 표준으로 자리잡고 있다. 실제로 넷플릭스, 핀터레스트, 골드만삭스와 같은 기업은 쿠버네티스의 승인 제어 및 마이크로서비스 API 권한 부여와 같은 사용례를 위해 이미 OPA를 프로덕션 환경에 구축했다. 또한 OPA는 아틀라시안(Atlassian) 제품군, 셰프 오토메이트(Chef Automate)와 같은 익숙한 여러 클라우드 네이티브 툴에도 사용된다.

OPA는 클라우드 네이티브 조직에 통합 정책 언어를 제공해 다양한 언어와 툴에 개별적으로 맞춤 정책을 하드코딩하지 않고 앱과 API, 인프라 등 전반에서 공통적인 방법으로 권한 부여 결정을 표현할 수 있게 해준다. 또한 OPA는 권한 부여를 목적으로 만들어진 만큼 여러 성능 최적화를 제공하므로 정책 작성자는 성능 문제는 OPA에 맡기고 올바른, 유지 관리 가능한 정책을 쓰는 데 시간을 투자할 수 있다.

OPA 권한 부여 정책의 사용례는 컨테이너 오케스트레이션을 위한 가드레일 설치부터 SSH 액세스 제어 또는 컨텍스트 기반 서비스 메시 권한 부여에 이르기까지, 스택 전반에 걸쳐 매우 많다. 그 중에서 많은 OPA 사용자에게 좋은 출발점이 되는 세 가지 인기 있는 사용례는 애플리케이션 권한 부여, 쿠버네티스 승인 제어, 마이크로서비스다.
 

애플리케이션 권한 부여를 위한 OPA

권한 부여 정책은 어디서나 사용된다. 거의 모든 애플리케이션에 필요한 요소이기 때문이다. 그러나 개발자는 일반적으로 “독자적인” 코드를 만드는데, 이는 시간 낭비일 뿐만 아니라 유지 관리하기 어려운 툴과 정책의 짜깁기로 이어진다. 권한 부여는 모든 앱에서 중요하지만, 정책을 만드는 데 시간을 많이 소비할수록 사용자 대면 기능에 집중할 시간은 줄어든다.

OPA는 권한 부여 정책 개발을 간단하게 해주는 전용 선언 정책 언어를 사용한다. 예를 들어 “외부 인력인 경우 PII를 읽을 수 없다” 또는 “OO는 이 계정에 액세스할 수 있다”와 같이 간단히 정책을 만들어 시행할 수 있다. 이것은 시작일 뿐이다. OPA는 컨텍스트를 인식하므로 세상에 존재하는 무엇이든 사용해서 정책을 만들 수 있다. 가령 “거래일 마지막 1시간 동안 요청된 주식 거래 중 거래액이 100만 달러를 초과하는 요청은 지정된 네임스페이스의 특정 서비스에서만 실행이 가능하다”와 같은 정책을 만들 수 있다.

물론 많은 조직은 이미 맞춤형 권한 부여를 실행하고 있다. 그러나 클라우드에서 개발자를 위한 효율성을 유지하면서 애플리케이션을 분해하고 마이크로서비스를 확장하려면 분산 권한 부여 시스템이 필요하고, 많은 경우 OPA가 그 답이 된다.
 

쿠버네티스 승인 제어를 위한 OPA

많은 사용자는 쿠버네티스를 위한 가드레일을 만드는 용도로도 OPA를 사용한다. 쿠버네티스 자체가 주류, 미션 크리티컬 기술이 되면서 조직은 보안 및 컴플라이언스 위험을 완화하기 위한 보안 가드레일을 정의하고 구현할 방법을 찾고 있다. 관리자가 OPA를 사용해서 명확한 정책을 설정하면 개발자는 운영, 보안, 규정 준수 위험에 대한 걱정 없이 파이프라인 프로덕션의 속도를 높이고 새로운 서비스를 신속하게 출시할 수 있다.

OPA를 사용해, 예를 들어 같은 호스트 이름을 사용하는 진입을 거부하거나 모든 컨테이너 이미지를 신뢰된 레지스트리에서 가져오도록 요구하는 정책을 만들거나, 모든 스토리지에 항상 암호화 비트가 표시되도록 하거나 인터넷에 노출되는 모든 앱이 승인된 도메인 이름을 사용하도록 보장할 수 있다.

OPA는 쿠버네티스 API 서버와 직접 통합되므로 컴퓨팅, 네트워킹, 스토리지 등 전반에서 정책이 허용하지 않는 모든 리소스를 거부할 수 있다. 특히 개발자에게 유용한 부분은 이런 정책을 CI/CD 파이프라인과 같은 개발 주기의 초기에 노출해서 개발자가 조기에 피드백을 받고 런타임에 앞서 문제를 교정할 수 있다는 점이다. 또한 정책을 대역 외로 검증해서 정책이 문제를 유발하지 않고 의도한 결과를 달성하는지 확인할 수 있다.
 

마이크로서비스를 위한 OPA

마지막으로, OPA는 조직에서 마이크로서비스와 서비스 메시 아키텍처를 제어하는 용도로 폭넓게 사용된다. OPA를 사용하면 마이크로서비스를 직접 대상으로 한 권한 부여 정책을 만들어 시행하고(일반적으로 사이드카), 서비스 메시 내에 서비스 대 서비스 정책을 만들거나 보안 관점에서 서비스 메시 아키텍처 내의 횡적 이동을 제한하는 정책을 만들 수 있다.
 

클라우드 네이티브 아키텍처를 위한 통합 정책 구축

일반적으로 OPA를 사용할 때 전체적인 목표는 클라우드 네이티브 스택 전반에서 정책 생성에 대한 통합된 접근 방식을 만드는 것이다. 그러면 많은 위치에서 다양한 언어와 접근 방법을 사용해서, 부족 지식과 위키, PDF 또는 이질적인 툴의 혼란스러운 조합을 통해 끊임없이 정책을 관리할 필요가 없다. 

개발을 간소화하고 제공 속도를 높이는 것 외에 보안 측면에서도 중요한 의미를 갖는다. OPA는 예를 들어 무단 액세스 시도가 있다고 의심되는 경우 확인해야 할 툴의 수를 줄여준다. 운영과 규정 준수 관점에서도 OPA는 이종 환경에서 정보를 가져오고 분석하는 과정을 더 쉽게 해주고 신속하게 문제를 파악하고 해결하는 데 도움을 준다.

개발자들은 클라우드 네이티브 환경에 맞는 정책 기반 컨트롤을 만들고 관리하기 위한 더 간편하고 효율적인 방법을 찾는다. 많은 개발자에게 답은 OPA다. 지금 여러 위치에서, 여러 언어로 또는 여러 팀에 걸쳐 권한 부여 정책을 다루고 있다면 OPA를 사용해서 중복성을 없애고 속도를 높일 수 있을 것이다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.