Policy as a Service

전문회사가 살아남기 위한, 자동화된 Kubernetes 기반의 정책관리를 어떻게 해야 하는가? 에 대한 방안 제시

Transcript

1. Policy as Code를 활용한 Kubernetes 정책 관리 통합 Everything on Kubernetes, Kubernetes Anywhere 클라우드거버넌스앤아키텍쳐(주) 이상근
2. • 경력 • 대학 졸업한지 20년 정도, 그 후로 분산 시스템 관련 일만 했음 • 전공이 분산 시스템이어서 다른 거 하고 싶어도 안 시킴ㅠㅠ • MSA, Policy as Code 전문 기업 창업(2021.09) 후 운영 중 • 주로 일하는 분야 • Policy as Code, MSA, Cloud, Bigdata Engineering. ... • 주로 하는 일 • AA, TA, 개발, 컨설팅 등 • 특이 사항 • 세계 최초로 OPA (Open Policy Agent) 관련 책을 썼음 • http://acornpub.co.kr/book/opa-book • 영어 버전은 온라인에서 무료로 볼 수 있음 (https://sangkeon.github.io/opaguide/) • 클라이언트 사이드 로드밸런싱 기능을 직접 만들어 봤음 발표자 소개
3. 01 배경 02 Policy as Code 03 Kubernetes 플랫폼과 Policy as Code 적용
4. 01 배경
5. • 빠른 세상의 변화를 따라 잡아야 함 • 경쟁자보다 앞서야 된다는 강박 • IT 역량으로 경쟁자를 압박하고 도태시킬 수 있음 비즈니스 환경
6. MSA Kubernetes Private/Public Cloud 현재의 표준 IT 서비스 스택
7. • MSA는 각 서비스들의 각자도생, 독립성과 자율성 중요 • 그러나 공통의 관리(표준화 포함)가 필요한 부분도 존재 • 3A(인증, 인가, 감사) • 모니터링, 추적, 로그 관리 • 정책관리 • 현재 SSO를 통한 인증 통합이 활발함 • 인증이 통합되고 나면 그 다음 단계? MSA 정책 관리 필요성
8. 거버넌스 (Governance) 정책 (Policy) 권한관리 (Authorization) 권한, 정책, 거버넌스
9. • 위임이 해결책 • 각 서비스가 정책을 최신 상태로 직접 유지보수하는 것은 어렵 고 비쌈 • RDBMS가 모든 애플리케이션의 데이터 관리를 위임 받아 데이 터 관리와 정합성의 문제를 해결했음 • 정책을 위임받는 정책에 최적화된 시스템 필요 • 이러한 정책 관리 전문 시스템을 통한 위임의 개념이 Policy as Code 임 MSA 정책 관리 해법
10. 02 Policy as Code
11. • 정책을 애플리케이션 로직과 분리된 별도의 코드로 관리 • 정책은 자체적인 정책 언어를 사용해서 구현됨 • (RDBMS가 SQL을 사용하는 것처럼) • 정책 엔진에 정책 코드 처리를 위임함 • (RDBMS가 데이터 저장과 처리를 전담하듯이) • 애플리케이션은 정책 판단을 위한 정보만 넘기고 정책 엔진으로부터 판단 결과만을 받아서 처리 • (RDBMS에 JDBC로 쿼리를 넘기고 결과셋을 받아서 처리하듯이) • 정책 엔진은 라이브러리, 사이드카, 정책 서버의 형태로 애플리케이 션에 통합 될 수 있음 • 결국 Policy as (on its own) Code Policy as Code
12. Policy as Code 동작 방식
13. Sandboxing • 비즈니스 로직과 정책을 서로 분리 Codification • 정책의 내용이 코드이므로 한눈에 파악 가능 Version Control • Git을 통한 이력 관리가 가능 Testing • 애플리케이션 코드와 완전히 독립적으로 정책만 테스트할 수 있음 Automation • 정책 코드가 텍스트 파일이므로 외부 도구 연동/자동화가 용이 https://docs.hashicorp.com/sentinel/concepts/policy-as-code 참고 Policy as Code의 장점
14. • Kubernetes 기본 RBAC에 비해 고도화된 정책 관리 • OAuth, OIDC와 통합한 서비스 인증/권한 관리 • 클라우드 보안 솔루션의 보안 정책 • CI/CD, DevOps 정책 관리 • API GW의 API 호출 정책 관리 • ... Policy as Code 적용 분야
15. • Styra의 OPA(Open Policy Agent)와 Hashicorp의 Sentinel이 대 표적 • OPA (Open Policy Agent) : https://www.openpolicyagent.org • Sentinel : https://docs.hashicorp.com/sentinel • OPA와 Sentinel 모두 정책을 선언하는 자체 정책 언어를 가지고 있음 • 대부분의 Policy as Code 기술들은 OPA를 기반으로 함 Policy as Code 구현체
16. 03 Kubernetes 플랫폼과 Policy as Code 적용
17. • Kubernetes RBAC을 보완할 수 있음 • 획일화되고 천편일률적인 권한 관리에서 벗어난 고도화된 권한 관리 가능 • 수년 내 반드시 적용되어야 함 • 기존 컨테이너 보안 기술 PSP(Pod Security Policy)가 제거되고 외부 시스템에 처리가 위임될 예정 • 표준화된 패턴이 존재 • Kubernetes는 권한/정책 위임을 위한 웹훅 설계를 초기부터 가지고 있음 • 수년 간 성숙된 오픈소스(OPA Gatekeeper) 존재 Kubernetes 환경의 Policy as Code 적용
18. • 조직 별로 Kubernetes 네임 스페이스를 관리하는 케이스 • 예를 들어 기본적으로 <조직_코드>_<서비스 이름>_<prd/stg/dev> 에 대한 권한을 부여한다면? • RBAC(Policy as Data)로 관리한다면 • 새로운 조직이 추가/삭제 될 때마다 권한도 동기화해야 함 • Policy as Code로 관리한다면 • 네임 스페이스 규칙을 정하고 조직 코드에 따라 유효한 네임스페이스인지 체 크하는 코드를 작성하면 됨 Policy as Code/RBAC 비교 예시
19. • 사용 가능한 컨테이너 이미지 제한 정책 • 고객사 관련 부서에서는 특정 mysql 버전에 대해서만 기술 지원이 가능 • 운영계에는 개발도구/디버깅 심볼/root 계정이 제외된 이미지가 배포되어야 함 • 네트워크 관련 정책 • 운영계에는 노드 포트를 만들 수 없음 • 조직별로 연결 가능한 로드 밸런서가 다름 • 자원 관리 정책 • DB 인스턴스는 메모리 8GB까지 할당 가능 • Go 애플리케이션은 512MB 이상 메모리 할당 불가 • Java 애플리케이션은 메모리 1GB 할당 가능 Policy as Code를 적용한 Kubernetes 정책 구현 예 (1/2)
20. • 관리 용이성을 위한 정책 • 생성하는 네임스페이스 등에 조직별로 지정된 prefix로 구분해야 함 • 컨테이너에 운영계/개발계 등 레이블링이 되어야 함 • 서비스 안정성을 위한 정책 • 운영계에서는 별도의 PV가 없는 DB 인스턴스는 생성 불가하고 개발계 에서만 가능 • 운영계에서는 항상 AutoScaling이 구성되어야 함 • 보안성 강화 정책 • 협력사 직원은 프로젝트 개발 기간 종료 후 시스템에 접근할 수 없음 Policy as Code를 적용한 Kubernetes 정책 구현 예 (2/2)
21. OPA Gatekeeper Architecture
22. • OPA Gatekeeper를 통해 Policy as Code 구현을 위 한 OPA(Open Policy Agent) 정책 엔진을 Kubernetes에 통합할 수 있음 • 정책 엔진 통합만으로 Policy as Code 구현을 완료했다고 할 수 없음 • 정책 템플릿/정책 등의 개발 및 적용 필요 • Policy as Code 관련 관리를 위한 기능들이 Kubernetes 관리 플랫폼에 추가되어야 함 Kubernetes 플랫폼에 Policy as Code 통합
23. • 정책 컨트롤러 관리 • 프로비저닝 및 라이프사이클 관리 • 정책 로그 관리 • 정책의 처리 내역에 대한 통계/보고서, 검색, 백업 기능 • 내부 시스템 데이터 연계 • LDAP/AD 등 내부 시스템 정보 연계 • 기존 구축된 DB 연계 • 정책 관리 • Git 등을 통한 정책 이력/버전 관리 기능 • 정책 관리를 위한 정책 저장소 • 프로덕션 수준의 정책 라이브러리 플랫폼에서 통합해야 하는 기능들
24. 질문 및 답변
25. 감사합니다