[Devotion Young] - 쿠버네티스/앱 현대화 테크 세미나 후기

KangManJoo 2024. 10. 6. 02:02

지난 5월 29일 을지로 SKT 타워에서 진행한 쿠버네티스/앱 현대화 테크 세미나에 다녀온 후기를 써볼까 합니다. 😊

현재 클라우드 네이티브와 쿠버네티스를 관심있게 공부하고 있어 특히 즐거운 시간이었는데요,
본 포스팅에서는 세미나 내용을 정리한 글을 바탕으로, 부족하지만 중간 중간 제 사견과 기반 지식/서칭한 내용을 바탕으로 살을 덧붙여 공유하고자 합니다. ✍️

이번은 쿠버네티스/앱현대화 테크 세미나의 두 번째 시간으로, 지난 2월 28일 있었던 1부의 주제 "당신은 쿠버네티스를 어떻게 설치/관리하고 계시나요?" 에 이어
"당신의 쿠버네티스는 안녕하십니까? 를 주제로 진행되었습니다. (3부와 4부는 하반기 진행 예정이라고 하시니 참고해주세요 🧐)

이번 세미나 장소는 데보션영 발대식이 있었던 T타워 SUPEX 홀이어서 어렵지 않게 찾아갈 수 있었습니다.

행사장 앞에는 아이스커피와 간단한 다과들이 준비되어 있어서 좋았습니다.
(뜨거운 커피일 줄 알았는데 시원해서 기분이 좋았습니다.. ☺️)

이렇게 앞에는 타임테이블이 띄워져 있어, 리마인드 하고 들어가기 좋았습니다.

오프닝 세션

오프닝 세션에서는 쿠버네티스 소개와, 다양한 커뮤니티 소개가 있었습니다.

양승현 CTO님의 오프닝

오프닝에서는 2회차이다보니 쿠버네티스에 대한 아주 간단한 소개와, 클라우드 네이티브 애플리케이션의 배포 플랫폼으로서의 성장 가능성 등을 얘기해주셨습니다.
그리고 이번 쿠버네티스/앱현대화 세미나는 쿠버네티스 기술과 경험을 공유하는 시리즈로 앞으로 운영할 에정이라고 하셨습니다.

올해로 쿠버네티스가 10번째 생일이라네요 🥳

오픈인프라 한국 커뮤니티 소개

오픈인프라 한국 커뮤니티는 오픈인프라 파운데이션의 공식 유저 그룹입니다.
또한 오픈스택과 오픈 인프라 프로젝트에 관심있는 한국 거주인이면 누구나 참여 가능합니다.
주요 활동

정기 밋업
오픈 인프라 기술 스터디
아시아 지역 유저 그룹과 협업 및 협동 세미나
업스트림 컨트리뷰션 멘토링 프로젝트

다음 목표

오픈스택 엔지니어 양성을 희망하는 기업, 학교와의 협업 및 파트너십

아쉽게도 대표이신 조성수님은 당일 참여하시 못하셨지만, 영상으로라도 소개를 해주셔서 좋았습니다.
추가로 OSSCA 컨트리뷰톤에서도 OpenStack으로 참여하신다고 하니 많은 관심 부탁드립니다. 🙇🏻‍♂️

쿠버네티스 한국 커뮤니티 소개

쿠버네티스 한국 커뮤니티 소개는 데보션 오픈랩 K8s 스터디를 이끌어 주시고 계신 안승규 멘토님께서 진행해주셨습니다.
(현재 데보션 영 전용 K8s 스터디도 첫 미팅을 마친 상태입니다 👍🏻)
쿠버네티스 한국 커뮤니티는 CNCF에서도 공식 인정한 커뮤니티로, 국내에서 다양한 활동들을 이어오고 있습니다.
그리고 올해 9월 24일에 백범 김구 기념관에서 CNCF가 공식 후원하는 KCD (Kubernetes Community Day) Seoul 행사가 개최된다고 하니, 이또한 많은 관심 부탁드립니다.🙇🏻‍♂️

첫번째 세션 : Kubernetes 보안 '그카나마알아'📌

K8s Security : 그카나마알아란?

우선 들어가는 말로, 개발 커뮤니티 같은 경우는 다같이 함께 공유하며 성장할 수 있는 기회이므로, 그러한 가치를 느꼈으면 좋겠다고 하셨습니다. 데보션 파이팅💪🏻
그카나마알아는 원소의 알칼리성 원소들을 외우던 줄임말로, 단순 암기를 나타내기 위한 키워드입니다.
그렇다면 왜 단순 암기냐?
쿠버네티스는 이해나 보안 규칙을 정하기 좋게 생겼기 때문에, 보안 같은 경우는 어느정도 암기만 해도 거진 커버가 될 것이라고 하셨습니다.

단순하게 표현하자면, 쿠버네티스는 사실상 REST API 서버라고 봐도 됩니다.
따라서 K8s Security == REST API Security 라고 표현할 수 있는 것입니다.
쿠버네티스 내에서 지우거나, 업데이트하거나, 작성하는 것은 다 알아서 작동하고 이를 API 서버를 거쳐서 동작합니다.
그 말인 즉슨, 쿠버네티스는 서버가 API 서버 뿐이므로 쿠버네티스의 보안은 API 서버만 신경써도 되기 때문에, 보안이 상대적으로 간단하다는 것입니다.

Request가 발생하고, Resource에 접근하기 까지는 다음과 같은 과정이 필요합니다.
사람에 대한 권한 ➡️ 자원에 대한 권한 ➡️ Admission ➡️ 자원 접근
*Admission은? 쿠버네티스는 자원에 대한 내용을 볼 수 있다. 쿠버네티스 자원을 받을 때 어노테이션이나 레이블 등을 작성하도록 강제할 수 있는 등

Authentication

인증 : 대상이 스스로 주장하는 신원을 확인하는 행위입니다.
쿠버네티스는 내부적으로 유저 인증 정보를 저장하지 않고, 각각의 인증 시스템에서 제공해주는 신원 확인 기능을 통해 사용자 인증을 진행합니다.
쿠버네티스는 사용자 인증 체계를 전부 외부 시스템에 의존하고, 쿠버네티스에서 지원하는 신원증명 수단은 X.509, ID Token등이 있습니다.

X.509 방식 : 비대칭 암호화 기술을 이용한 공개키 기반 인증 체계인 PKI 기술의 표준 포맷으로,
보통 우리가 kubectl을 쓰면 인증서를 API 서버에서 먼저 보내고, 그 다음 클라이언트가 자신의 인증서를 보내고, 통신이 연결됩니다.
X.509를 사용한 암호화는 자신의 신원은 자신만 가진 비밀키로 암호화 하는 것이고, 공개키를 분배하는 방식은 정해져 있지 않기 때문에 알아서 잘 해야 합니다.
ID Token 방식 : 토큰에 전자성명을 넣어서 서버에 전달하고, 발행 기관에 해당 토큰의 검증을 위임합니다.
➡️ 따라서 인증서를 안전하게 배포하는 과정이 필요없어진다.

즉, 인증 대상에 따라 인증 방식을 다르게 사용할 수 있습니다.

고정된 경우 : X.509 ex) kube-scheduler
다이나믹한 경우 : ID Token ex) User, Pod 등

(이전 세션에서 쿠버네티스 설치는 X.509 인증서 배포가 전부라고 했었는데, 이 말인 즉슨 결국 API 서버와 통신하려면 인증서를 배포하는 과정을 결정하는 것이 중요하다는 의미.)

Authorization : RBAC(Role-based access control)

내가 어떤 API에 접근할 수 있는지를 정한 것이 Role이고, Role을 만들고 나면 Role Binding을 하게됩니다.
Role Binding ? ➡️ 권한이 어떤 대상에 매핑되는지 바인딩 하는 것
자세한 내용은 공식문서 참조 ➡️ 링크

Admission

Admission은 그 자원의 내용까지 보게 됩니다.
다양한 개발자들이 룰을 지키는지 하나하나 확인할 수도 없고,, 관리하는 측면에서 그러한 룰을 어떻게 지키게 해야 할까요?
위 그림을 보면, 해당 사람은 범위내에서 할 수 있는 일은 다 할 수 있지만, 줄이 허용하는 범위 내에서만 움직일 수 있습니다.
즉, Admission은 제약없이 동작할 수 있게 하지만, 허용되지 않는 부분에 접근할 시 에러가 발생합니다.
관리자가 하지 말아야하는 일, 정책만 잘 짜게 되면 모든 사람이 행복해지는 결과를 만들 수 있습니다.

DEVOCEAN

데보션 내에 규호님이 만든 K8s 보안 관련 시리즈가 있으니, 해당 시리즈도 참고 ! ➡️ 링크

두번째 세션 : OIDC를 이용해 동적으로 쿠버네티스 접근 제어하기 📌

Native Kubernetes 접근 제어 방식

온프레미스에 클러스터를 구축하고, 어떻게 쓰고 있는지를 보면 보통 인프라 운영자가 클러스터를 관리합니다.
그리고 여러 종류의 서비스를 개발하는 개발자와 운영자가 kubectl로 접근해 사용을 하게 됩니다.

클러스터 관리자가 해야하는 작업

문서관리 : fluentd, excel 등으로 관리.
kubeconfig 발급
RBAC 설정 : 문서에 작성된 대로 RBAC를 설정해준다.

kubeconfig란?
일종의 config파일로, 클러스터 정보와 유저 정보로 구성되어 있다. 이를 묶은 컨텍스트 정보도 포함.
클러스터 정보는 cluster URL, certificate-authority-data 등

여기서 문제점 !

➡️ 최신화 이슈와, 클러스터 관리자가 할 일이 너무 많다는 문제점 ..
특히 사용자의 역할이 바뀌게 될 경우 한 번 Service Account를 만들며 발행한 Token을 폐기하고 재발행 해야하는데,
클러스터 관리자 입장에서 사용자가 이를 진행한다는 것을 신뢰할 수 있는지?

OIDC를 활용한 kubernetes 접근 제어 방식

OIDC란?
중앙 인증 서버를 두어, 쿠버네티스에 접근할 때 중앙 인증서버에서 인증 정보를 받아 접근할 수 있도록 하는 기술.
➡️ 정보 관리 툴 개선과 클러스터마다 작업할 필요 없이 중앙 인증 서버만 수정하면 됨.

중앙 인증서버에서는 전체 사용자 정보와 사용자 역할 등을 관리합니다.

그리고 모든 역할에 대한 kubeconfig파일이 동일합니다. oidc-plugin을 포함하기 때문에 중앙인증서버에 자격 증명 후 동적으로 토큰을 받아오게 됩니다.

oidc-plugin이란?

kubectl 실행시 플러그인에 의해 kubelogin이 실행되고 ➡️ 브라우저가 열리고 ➡️ OIDC 프로바이더 (인증서버)로 연결하고 ➡️ 유저가 Authenticate 하는 과정으로 진행됩니다.
하지만 OIDC를 활용해도 여전히 문서 관리와 RBAC 설정은 클러스터 관리자가 해야한다는 단점이 있습니다.

TKS의 쿠버네티스 접근 제어 방식

TKS란? ➡️ 링크

TKS는 문서관리와 RBAC도 자동화 하기 위해 나온 방식입니다.
TKS UI에서 클러스터 관리자가 모든 작업을 하고, 기존에 OIDC에서 하던 작업들을 TKS Backend에서 자동화로 처리하게 됩니다.

OIDC, TKS를 도입하면서 생긴 개선 사항

중앙 집중화 된 신원 정보 관리
- 사용자 및 kubernetes 별 역할을 중앙 집중화 된 인증 서버에서 관리
- 사용자와 역할 간의 관계 정리
쿠버네티스가 여러 개 되더라도 단일 인증 서버 사용
RBAC 설정 자동화
관리를 전부 UI화

TKS 동작 방식 오버뷰

기술 구성

인증(Authentication)

사용자가 서버에게 자신이 누구인지를 증명하는 과정

자격 증명 : 사용자는 자신의 신원을 증명하기 위한 자격 증명 제출
신원 검증 : 제출된 자격 증명 정보를 기존 등록된 계정 정보와 비교하여 사용자의 신원 확인
결과 전송 : 검증 성공 시 사용자는 인증된 것으로 간주하여 시스템에 접근 가능한 인증 토큰 발급
인증 토큰 검증 : 제출된 인증 토큰 유효성 검증 & 신원 확인

사용자는 모든 HTTP 리퀘스트에 인증 토큰을 포함해 서버에 요청을 보내고, 해당 토큰을 바탕으로 사용자를 검증합니다.

인증 토큰은 어떻게 생겼나?

JWT : 대중화되고 일반적으로 사용되는 토큰
OpenID Connect : ID Token이라는 JWT를 이용해 최종 사용자 신원 정보를 전달하는 인증 프로토콜로, 신원 정보를 포함한 claim을 전달한다. 이메일, 이름 등등..

인가(Authorization)

RBAC과 관련된 내용으로, 인증된 사용자가 어떤 작업을 수행할 수 있는지를 결정합니다.

권한
- 특정 사용자가 특정 자원에 대해 어떤 작업을 수행가능한지
- Match
  - http의 경우 일반적으로 http요청에 첨부된 token,method,path 등을 활용
- action
권한 관리 방식
- ABAC : 주체, 자원의 속성을 기반으로 권한 부여
- RBAC : 주체의 Role을 기반으로 권한 부여

Kubernetes의 RBAC 설정

subject를 통해 주체를 정의하고,
roleRef를 통해 자원과 행위를 정의합니다.

Token 기반 인증/인가 동작 흐름

위 그림과 같이 사용자 인증 시 토큰에 클러스터 어드민이라는 정보를 포함하면, RBAC에서 클러스터 어드민에 대한 권한을 설정합니다.

세션 3 : Kubernetes에게 policy이란? 📌

정책은 인증과 인가를 넘어, 인가를 포함한 더 넓은 범위입니다.
권한이 아닌 정책의 예 : 네이밍룰, 세션관리 등등..
API의 접근여부 뿐만 아니라 파라미터와 세션 정보 등도 확인합니다. (방화벽으로 비유하면 WAF 같은 느낌?)

쿠버네티스의 정책관련 지원기능

RBAC: 사용자와 그룹에 대한 권한을 할당하여 제한
PSP: Pod에 정의하여 행위를 제한
Network Policy: 네트워크 트래픽을 제한
Admission Policy
- CEL이라는 언어를 사용해 정책을 규정

쿠버네티스 용 정책관리 도구

kyverno, OPA Gatekeeper, OPA, Istio 등등..

Gatekeeper는 폭넓은 정책의 정의와 외부 데이터를 활용하는 것이 가장 큰 장점으로, sk에서도 주로 사용중이라고 합니다.

도구 별 사용 방법

gatekeeper는 템플릿을 생성 후 템플릿을 찍어내 정책에 적용합니다.

배포형상
- 게이트키퍼는 k8s api 서버에 연동되어 사용되므로 클러스터별로 동작
- 하나의 게이트키퍼를 같이 쓸 경우 상시 클러스터 외부로 연동되는 문제가 있으므로 개별 클러스터 별로 게이트키퍼 배포

kyverno같은 경우는 rule을 정의. 코드가 복잡하지 않고 클러스터 폴리시를 적용하는 부분이 복잡했던 코드를 validate에 작성하여 구현합니다.
PSA는 단순한 작업을 하기 때문에 구조도 단순합니다. 클러스터 수준에서는 PSS관련 설정을 kube-api에 추가하여 실행합니다.
Validating Admission Policy는 validation에서 cel 언어로 정의합니다.

OPA(Open Policy Agent)

OPA는 범용 정책 엔진으로, MSA/K8s 환경에 적합합니다.
Rego라는 전용 언어를 사용하여 로직을 정의(정책의 코드화)하고, JSON으로 컨텍스트를 전달, 엔진이 JSON에 대한 판별을 해줍니다.
Rego의 특징

선언한 규칙들의 나열
main은 없음
입력과 데이터 영역을 가짐

Policy as Code의 이점

정확정, 투명도 향상
재사용
검증 및 테스트 가능
버전관리, 저장소

TKS의 Policy serving

TKS는 서비스, 설치형 KaaS 솔루션입니다.

서비스에 조직을 등록하고 조직 별 k8s 클러스터를 생성/변경/삭제 기능 제공

멀티클러스터 기반 KaaS로써,

배포관점에서 클러스터 그룹지원
운영관점에서 클러스터 그룹지원

그 밖에도

복잡성을 추상화, UI 제공
다양한 에코시스템과의 유기적 결합
loud Native 환경에서 거버넌스 조직에서 일관된 정책을 강제할 수 있도록 기능 추가

Policy Service

TKS는 TKS 통합 포털에서 쿠버네티스의 특징을 활용해 다음과 같은 통합 거버넌스를 제공합니다.
Kubernetes 기반 Admission Control

클러스터에서 정책을 강제
정책 위반 시 배포 원천 방지

Fine-grained Policy

프로그래머블 정책 개발 가능
기존 대비 상세한 업무 flow 적용 가능

정책의 일괄 적용

필수 정책의 강제화 설정 가능
관리 부서의 거버넌스 강화

이후 내용은 TKS 사용 예시, 시나리오,Gatekeeper 설정 등에 대한 예시들이 있었습니다.
해당 내용들은 TKS에 대한 도메인 지식 부족으로 열심히 청강만 했습니다 💦

++ TKS Policy 교육준비 중!!
6월 중, Rego 문법 및 정책작성 실습, 정책의 적용 및 활용 방법에 대한 교육 등이 준비 중이라고 하십니다.

네번째 세션 : 쿠버네티스 워크로드 보안? 어떻게 동작하는거니?

네번째 세션은 쿠베아머의 메인테이너이신 남재현 교수님께서 진행해주셨습니다.
유일하게 이력을 준비해주셨는데, 다른 스피커 분들도 마찬가지시지만 이력이 정말 화려하셔서 놀랐습니다..
CNCF 샌드박스 프로젝트의 kubearmor maintainer이신 건 알았지만 레포를 만드셨다는게 너무 신기했어요.

쿠버네티스 워크로드 보안이란?

쿠버네티스 클러스터 내에서 실행되는 애플리케이션과 서비스를 보호하는 것

어떻게?

Pod 보안 ➡️ 이미지 보안, 민감 데이터의 안전한 처리, 취약성 관리 등
네트워크 보안 ➡️ 쿠버네티스 클러스터 내/외부 트래픽 흐름 제어
접근 제어 ➡️ 쿠버네티스 리소스에 대한 접근 제어
데이터 보호 ➡️ API 키, 비밀번호 등 민감 정보를 안전하게 저장, 관리
런타임 보안 ➡️ 런타임에 발생할 수 있는 보안 위협을 감지하고 대응
컨테이너 보안 ➡️ 적절한 컨테이너 런타임 설정, 불필요한 권한 제거
감사 및 로깅 ➡️ 클러스터 내에서 발생하는 모든 활동을 로깅, 이를 통해 보안 사고 원인 분석

쿠버네티스 환경에서 워크로드 보안을 강화하는 법은 무엇이 있을까?

RBAC
- 사용자, 서비스 계정 또는 그룹 등을 통해 특정 리소스에 대한 접근 제어
- 필요 이상의 권한이 부여되지 않도록 보안 유지
쿠버네티스 시크릿
- 비밀번호, OAuth 토큰 등 민감한 정보 저장
네트워크 정책
- 특정 pod간의 트래픽 흐름을 제어
- 워크로드 간 네트워크 격리
Admission Controllers
- 오브젝트가 쿠버네티스 API 서버로 요청될 때 이를 가로채 검증 및 수정 작업 수행
- 쿠버네티스 클러스터의 요청을 사전에 처리하고 필요한 보안 조치를 적용 가능

단계별 보안

Admission까지 통과되면 서비스는 안전한가?
실제 서비스를 배포했을 때 서비스가 동적으로 변화하는 것이 굉장히 많습니다.
특히 프론트엔드를 외부에 노출시켰을 때 기존의 취약점들 컨테이너에서도 동일하게 존재하고, 컨테이너로 공격자들이 돌아와 다양한 공격을 시도할 경우 시스템이 취약해집니다.
*따라서 런타임에서도 중요한 솔루션이 필요하다.

실시간으로 바뀌는 것?

워크로드
- 실시간으로 애플리케이션이나 서비스들이 생성되고 또 삭제됩니다.
시스템 ➡️ 워크로드가 바뀌면 동작 패턴도 함께 바뀐다
네트워크 ➡️ 워크로드가 바뀌면 네트워크 패턴도 함께 바뀐다
API ➡️ 워크로드가 바뀌면 API 패턴도 함께 바뀐다

즉, 워크로드만 변경해도 다양한 영역이 영향을 받습니다.
어플리케이션 레벨이 아닌 쿠버네티스 클러스터 입장에서 런타임 시큐리티를 어떻게 할 수 있을까?

시스템 레벨에서의 워크로드 보안

eBPF* 기반으로 시스템 동작 모니터링
쿠버네티스 API를 통해서 각종 리소스 정보 수집
악성 행위에 대한 Alerting 제공
악성행위란, 우리가 생각하는 악성 행위가 아닌 보안 정책에 위배되는 모든 행위!

eBPF란?
리눅스 커널에서 실행되는 프로그램을 위한 확장 가능한 프로그래밍 인터페이스
초기에는 네트워크 분석 및 패킷 필터링을 위해 사용
현재는 네트워크,보안,모니터링,디버깅 등에서 사용

시스템 레벨에서의 보안 정책

시스템 레벨의 보안 정책은 어떻게 생겼을까?
쿠베아머와 테트라곤 모두 보안 정책을 규정합니다.
이때 테트라곤은 너무 low level에서 보안 정책을 규정해야 한다는 아쉬운 점이 존재합니다.

시스템 레벨에서의 액션

기본적으로 보안 정책들은 비정상적 상황을 탐지하였을 때 다양한 액션을 취합니다.
특정 프로세스, 컨테이너를 죽이는 등등..
killing something = 서비스 중단
➡️ 프로세스를 죽이거나 컨테이너를 죽이는것 모두 서비스의 장애를 유발합니다.
이게 과연 진정한 해결법인가?
Dos 공격 등으로 서비스를 중단시키는 것이 공격자의 의도가 아닐까? 데이터 정합성이 깨지거나 리커버리 전략이 잘 되어있지 않다면?
그렇다면 상용제품은 오픈소스SW보다 좋을까?
오픈 소스인 Sysdig's Falco와 상용제품인 secure을 비교해봤을 때, 결국 secure도 시스템을 죽입니다.

Post-Exploit Mitigation

공격을 탐지하고 나서 공격 차단을 시도하는 것은 너무 많은 시간을 주므로, 시도를 보자마자 차단해야 합니다.

Inline Mitigation

따라서 Inline Mitigation이 제안됩니다.
쿠베아머가 Inline mitigation을 제공하는 법: 리눅스 시큐리티 모듈을 가지고 인라인에서 컨트롤하고, 프로세스를 죽이는게 아닌 해당 작업에 에러를 띄웁니다.
그럼 inline mitigation은 어떻게 작동하는가 ?

Inline Mitigation 동작

탐지를 하려면, 다양한 정보를 모니터링을 합니다.

프로세스 실행
파일 접근
네트워크 통신
시스템 콜 호출

위 정보들을 eBPF를 사용해 모니터링을 하게 됩니다.
그리고 eBPF는 시스템콜이나 LSM Hook을 수집해 어떤 액션들이 발생했는지 알 수 있습니다.

차단은 어떻게?

LSM hooks
- 리눅스 커널 내부에 다양한 hook 존재
BPF-LSM
- eBPF 프로그램을 LSM Hook에 붙여서 차단

네트워크 정책은 어떻게 동작하는가

iptables 기반이라면, 다양한 iptable 룰을 만들게 됩니다.
그러나 generation까진 해도, 검증이 불가능합니다.
따라서 eBPF 기반으로해서 ARP도 핸들링이 가능해지고, policy매칭도 가능해집니다.
그리고 packet을 하나하나 decoding해서 보안 정책이랑 Matching하는 방식으로 진행됩니다.

API 레벨에서의 워크로드 보안

API 보안은 서비스 메시와 밀접합니다. MS 간 통신 시 API를 활용하기 때문에.
같은 API라도 인가에 따른 사용이 중요
즉, 네트워크 보안 정책보다 구체적인 정책으로 구성

또한 Istio, Linkerd 등의 서비스메시 솔루션을 사용할 때 서비스 간의 API 호출을 로깅해줬을 때 로깅을 하면서 자연스럽게 차단도 가능합니다.

API를 표현할 때 정규표현식을 쓴 경우 , 매칭이 너무 복잡해집니다.
다양한 Policy를 만들어야 하고 Envoy단에서 매칭을 해야합니다.

그럼 API 시큐리티에서도 eBPF를 쓴다면?
그러나 커널 콜을 하는데 정규식 매칭을 구현하기에는 제약이 많습니다. 우선 성능이 보장이 안되는 부분 등

User-space의 Proxy를 사용한다면 Envoy는 유저스페이스에 있으므로 패킷이 나가는 순간 커널로 내려갔다가 유저스페이스에서 정규식 매칭을 하고, 다시 커널로 나간다.
➡️ 성능을 보장하려면 Policy를 많이 정의할 수 없습니다.

그래서 User-space의 Proxy를 사용한다고 합니다. (아키텍처는 이해가 어려웠습니다 💦)

맺음말

쿠버네티스 환경에서 다양한 워크로드 보안 솔루션들이 존재하고,
런타임에서 워크로드의 보안을 강화하기 위해선 시스템/네트워크/API 레벨의 보안 솔루션이 필요하지만 매우 어렵다고 합니다.

추상화된 개념이 아닌 실질적인 동작에 대한 이해가 필요하다.
➡️ 시스템콜, 프로세스 실행, 파일접근, 네트워크 통신, 프로토콜, 포트, API, 패턴, 정규표현식 ..

결론 : 워크로드 보안은 정말 쉽지 않다.

Q & A

네 개의 세션이 모두 끝나고, 간단한 Q&A가 진행되었고, 몇 가지만 정리해보았습니다.

TKS와 키클락의 차이점은?
➡️ 키클락은 좋은 솔루션이지만 oidc만 지원하는 것이 아닌 다양한 솔루션을 제공한다.
따라서 키클락의 ui를 사용하려면, oidc만 알아서는 사용하기 어렵다. 따라서 키클락이 러닝 커브가 높기 때문에 tks는 많은 부분을 추상화하는 것에 중점을 두고 만들게 되었다.

TKS에서 추가된 것은?

프로젝트라는 개념이 존재한다. 클러스터와 클러스터에 어떤 네임스페이스를 쓸지를 지정 가능하다.
이는 멀티 클러스터 환경에서 동일한 네임서버에 어떠한 액션을 부여하는 것을 염두에 두고 제작하였다.
권한과 역할 자동 define 가능

API 서버의 인가되지 않은 위치에서 request를 제한하기 위해 네트워크 상 노출 범위를 최소화하기 위한 효율적인 방안은?
➡️ 물리적인 노출은 어쩔수 없고, 온프레미스에서의 노출은 방화벽을 두는 것이 결국 해결책이 되지 않나 싶다.

비록 제가 쿠버네티스와 policy에 대한 도메인 지식이 부족해 내용이 많이 어려웠던 점이 아쉬웠지만, 그럼에도 4시간이 정말 짧게 느껴질 만큼 알차고 재밌는 세미나였습니다. + 더 열심히 공부해야겠다는 자극도 많이 받았습니다 ㅎㅎ 하반기에 있을 다음 세미나도 정말 기대가 되고 이런 좋은 기회를 제공해 주신 스피커 분들과 데보션에 진심으로 감사드립니다 🙇🏻‍♂️

#DEVOCEANxKubernetesKoreaGroup