Devocean Kubernetes 세미나 후기: 당신의 쿠버네티스는 안전하십니까?

1. Opening

세미나 주제: 당신의 쿠버네티스는 안전하십니까?

1. 쿠버네티스 설치하기
지난 세미나에서 진행했었다. 후기는 아래 링크에서 확인 가능
https://devocean.sk.com/blog/techBoardDetail.do?ID=165694

• 하반기에 다른 주제를 다룰껀데 아래 링크를 통해 주제를 어떤것으로 할지 의견을 접수한다.
• https://form.naver.com/response/CoRBpQsKAYpnhGM7Deu6aw

• 오늘 세미나 간 질문은 아래 링크에서도 가능
• https://app.sli.do/event/x9JjP5axFPGWjdStsPegxK/live/questions

2. 커뮤니티 소개

2-1. OpenInfra 에 대한 소개

• 오픈스택과 오픈 인프라 프로젝트에 관심있는 한국 거주인 누구나 참여 가능’

• 주로 facebook 그룹에서 많은 정보교류를 하고 있다.

2-1-1. 주요 활동

• 정기 밋업(온라인/오프라인)

• 오픈 인프라 기술 스터디

• 추 후 목표
• 오픈스택 엔지니어 양성을 희망하는 기업과 학교와의 협업 및 파트너십

2-1-2. 향후 일정

• OpenInfra summit > ASIA’24

2-2. Kubernetes Korea Group

• 간략한 소개

• CNCF Graduated Project
쿠버네티스를 첫번쨰로 여러 프로젝트들이 진행중이다.

• KubeCon 유럽의 상황을 보면 처음 참석자가 52%다. 2018년을 기점으로 폭발적으로 증가하였다.

• 9월 24일 화요일 쿠버네티스 코리아 커뮤니티데이 일정이 예정되어있다.

3. Kubernetes 보안 ‘그카나마알아’

k8s 보안의 핵심. REST API Security

• Authentication (인증)

• Authorization (인가, 권한부여)

• Accounting (계정 관리)

• Authentication

• Authorization

• Admission
❓
Admission Kubernetes Admission Controllers는 클러스터에 대한 API 요청을 가로채어 유효성을 검사하고, 승인 여부를 결정하는 중요한 구성 요소입니다. Admission Controllers는 요청이 etcd에 영구적으로 저장되기 전에 트리거되며, 요청이 인증(Authorization) 및 권한 부여(Authentication) 단계를 통과한 후에 실행됩니다.

• Mutating : 요청된 객체를 변경할 수 있다.
• 예시 : AlwaysPullImages는 모든 새로운 Pod에 대해 이미지 풀 정책을 'Always'로 설정합니다.
• 단계: 어드미션 컨트롤 과정의 첫 번째 단계에서 실행됩니다.
• 목적: 객체의 기본 값 설정, 추가 데이터 삽입 등을 통해 객체를 수정합니다.
 

• Validating : 객체를 변경하지 않고, 요청된 객체가 정책을 준수하는지 검증합니다.
• 예시: PodSecurity는 새로운 Pod의 보안 설정을 검증합니다.
• 단계: 어드미션 컨트롤 과정의 두 번째 단계에서 실행됩니다.
• 목적: 객체가 클러스터의 보안, 리소스 제한 등 정책을 준수하는지 확인합니다.

Authentication (인증)

• 대상이 스스로 주장하는 신원을 확인하는 행위

• 종류
• X.509 (인증서)
• ID Token (HTTP 헤더부분에 들어가는 토큰)

• ID Token 방식은 검증을 OIDC 라는 기관에 위임한다.
💡
OIDC OpenID Connect (OIDC)는 사용자가 안전하게 인증할 수 있도록 하는 간단하고 확장 가능한 인증 프로토콜입니다. OIDC는 OAuth 2.0 프로토콜을 기반으로 하며, 사용자 인증 및 정보 제공을 위한 추가적인 레이어를 제공합니다. OIDC는 클라이언트 애플리케이션이 사용자 정보를 요청하고, 인증된 사용자인지 여부를 확인할 수 있도록 해줍니다. 예를들어 특정 웹사이트에서 로그인 시 Google로 로그인하기 등이 OIDC가 적용되었다고 볼 수 있다.

Authorization (인가, 권한부여)

보안에 이상향. 이상점은 무엇일까에 대한 고민

• 개발자가 신경쓰지 않고 행위를 한다. 그때 잘못되거나 문제되는 행동은 아예 명령이 안먹도록 설정하는 것

• 허용된 범위 안에서 자율성을 보장한다

4. OIDC를 이용해 동적으로 Kubernetes 접근 제어하기

Native Kubernetes 접근 제어 방식

• 각 업무자 마다 이해관계가 다르다. 예를 들어 클러스터 관리자는 클러스터의 안전이 우선 , 개발자같은 경우는 마음껏 조작할 환경 , 서비스 운영자는 서비스의 정상동작 여부

• 접근 제어의 니즈가 생긴다.

• 클러스터 관리자는 기본적으로 문서관리로 출발한다. (일반적으로 액셀로 많이 본거같다)

• 문서에 어떤 개발자가 어떤 시스템의 어떤 권한이 필요한지 파악을 해야한다.

• 이후에 RBAC 설정을 해주고, kubeconfig 발급을 진행한다.

• 사용자에게도 서비스 어카운트를 만들어서 아이디 패스워드 주고 ID Token 방식으로 해서 kubeconfig 발급을 하고 저걸 관리자로부터 전달받아서 클러스터에 접근을 해서 접근한다.

1. 문서 관리의 어려움

2. 고정된 토큰 (토큰 회수가 현실적으로 불가능하다)
사용자 A가 역할이 B 서비스 개발자로 바뀌었을때. 과연 기존의 토큰을 폐기할까?

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

• 빨간색 부분은 OIDC를 도입하므로써 자동화할 수 있는 영역이다.

• OIDC 는 중앙 인증서버를 둬서 쿠버네티스에 접근을 할때 인증서버로 부터 정보를 받아와서 접근할 수 있게 하는것

• Auth Server 에서 전체 쿠버 사용자 리스트 관리를 하고 , 역할까지도 서버에서 관리를 하게 된다.

TKS의 Kubernetes 접근 제어 방식

• TKS는 RBAC 설정까지 자동화

기술구성

• 간략한 구성도



 

• 인증
• 사용자가 서버에게 자신이 누구인지를 증명하는 과정
• 주요 Step
1. 자격증명 : ID /PW 입력이나 Face ID 등
2. 신원검증: Auth server 에서 정보 비교 후 파악
3. 결과 전송: 검증이 성공하면 인증 토큰 발급
4. 인증토큰 검증: 유효성 검증 & 신원 확인
• 개인화된 서비스 제공 & 자원 보호

• 인증 토큰은 어떻게 구성되어있는지?



• header
• payload
• iss : 토큰을 발행한 인증 서버의 URL
• iat : 토큰이 발행된 시간
• exp
• aud : 나를 위한 토큰이 맞는지 검증
• sub
• signature : 검증 용도

• OpenID Connect
• ID Token 이라는 JWT를 사용하여 최종 사용자 신원 정보를 전달하고 인증 프로토콜
• 커스텀 Claim 정보를 넣을 수 있다.

• 인가
• 인가는 인증에서 확인된 신원정보를 바탕으로 인가를 하게 됨
• 어떤 사용자가 어떤 작업을 수행할 수 있는지를 결정하는 과정
• 권한
• 특정 사용자가 특정 자원에 대해 어떤 작업을 수행할 수 있는지를 결정하는 규칙
• Match
• 주체, 자원, 행위
• HTTP의 경우 일반적으로 HTTP 요청에 처뭅된 Token, Method, PATH를 활용
• Action
• 허용
 
• 권한관리방식
• ABAC
• RBAC

5. 자동화된 정책으로 클라우드 보안 및 운영

Kubernetes 정책관리

• 인증과 인가를 넘어서
거버넌스의 일부분이면서 인가 자체를 판단하고
• 권한이 아닌 정책의 예 : 네이밍룰 , 세션관리
RBAC 에서 role 하나에서도 개별적인 처리가 필요할 수 있다.
API 접근 가능여부 이상의 것이 필요 → 세분화의 필요성

• 쿠버네티스의 정책관련 지원기능
• PSP : pod security Policies Pod에 정의하여 행위를 제한
• Network Policy : 네트워크 트래픽을 제한
• Admission Policy : 1.30 에서 추가 , CEL 이라는 언어로 정책을 구성

• Kubernetes Admission Controller
• mutatung / validating
예를들어 pod를 정의할때 . 굉장히 많은 정의들이 들어가 있는데 이런게 mutation에서 해주는것
(mutating 과정이 Webhook에서 정책을 비교해서 pod의 정의를 수정해주는 로직이라고 생각됨)

• Kubernetes 용 정책관리 도구 소개



• Gatekeeper
장점 : 폭넓은 정책의 정의 , 외부데이터 활용
단점 : 복잡한 시스템 구성, 별도의 webhook 으로 구성
결국에는 외부데이터 활용이 중요해서 채택하였음
(Gatekeeper, OPA, Istio에 대해서는 deepdive 까지는 아니어도 조금 공부해두면 좋을것 같다)
 

• 정책관리별 장단점 비교

기반기술 소개

• OPA : Styra에서 개발한 범용 정책 엔진



• MSA/k8s 환경에 적합한 정책 엔진
• Go 기반 오픈소스
• CNCF graduate 프로젝트
• 정책 전용 언어 (Rego) 사용
• Policy as Code
• OPA는 Prolog 기반 정책정의 언어인 REGO를 사용하여 정책의 코드화
• Rego의 특징
• 선언한 규칙들의 나열
• main은 없음
• 입력과 데이터 영역을 가짐
• Policy as Code 사용의 이점
• 정확성, 투명도 향상
• 재사용
• 검증 및 테스트 가능
❗
Prisma에서도 OPA 기반 액세스 컨트롤 정책이 있음 Rego 언어로 커스텀룰을 설정할 수 있음 즉 OPA의 구조와 Rego언어의 기본적인 습득이 필요함

• Gatekeeper





• k8s API 요청이 쿠버네티스 자체 인증 및 인가를 Admission controller 단계에서 실행
• Mutatuion 지원 GateKeeper에서 직접 만든 엔진을 통해 지원
• 구성요소
• Controller : Webhook 자체의 구현체 , kube api로 요청이 들어오면 controller 에서 정책을 판단해서 결정
• Auditor : 스케줄러 , 배치 프로세스
• 정책의 수행
• 입력된 제약사항(Constraint)를 기반으로 감사
• 감사의 타입
• Deny : 차단
• Warn : 경고정도의 의미
• Dryrun : 말하긴하는데 Auditor 가 돌아가면서 운영자에게 noti를 해줌

TKS Policy Serving

• 서비스, 설치형 KaaS 솔루션
• 서비스에 조직을 등록하고 조직 별 k8s 클러스터를 생성/변경/석재 기능 제공

• 클라우드 네이티브 환경에서 거버넌스 조직에서 일관된 정책을 강제할 수 있도록

• Kubernetes 기반 Admission Control
• 클러스터에서 정책을 강제
• 정책 위반시 배포 자체를 원천 방지

• Fine-grained Policy
• Programmable 정책 개발 가능(코드화)

Demo

• 정책엔진
• Gatekeeper 선택

• 정책 스케줄러
• 다중클러스터 지원 이슈
• 정책엔진은 각각의 클러스터에 배포함

• 관리포탈
• 사용자 관점에서는 파라미터만 정의하면 됨
• 정책에만 집중할 수 있도록 구성

• 자원 사용량 , 노드포트 통제, 고가용성 강제(최소 파드 3개 이상 등)

• 소프트웨어 사용통제 ( 명명 규칙 .. 등 )

Lession learned & Futur work

• Gatekeeper 설정
• 삭제에 대한 audit 추가
• 정책 위반으로 거부된 내역에 대해 로그기록 ..
• 장애설정에 대한 처리. gatekeeper 가 장애가 나도 api-server 가 마비되지 않도록
• input 데이터 이외의 자원 접근 시 권한설정 (사용자 자원 추가)
• 외부의 데이터를 함께 사용 가능

• Custom controller 개발
• 초기에 CR을 잘 설정
• Spec 과 Status 를 명확하게 분류
• 외부에서는 Spec 영역 변경
• Reconcile 내부에서는 Status 영역 변경
Reconsile loop ?
• 멱등성 고려
멱등성?
 

6. 쿠버네티스 워크로드 보안? 어떻게 동작하는거니?

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

• How?
• 네트워크정책
• Pod 보안 정책
• 서비스 계정
• RBAC
• Secret
• Admission Controllers

• 단계별 보안



1. 개발자들이 코드를 작성하고 CI단에 보안이 들어간다.
2. Admission : 앞서 보았던 쿠버네티스 상의 보안
3. Runtime : 지금 강의에서 핵심이 되는 영역. 컨테이너가 실행중일때 보안
• 동적으로 변하는게 굉장히 많다.
• 컨테이너로 공격자들이 들어와서 행위를 하게 되면 . 취약

• 워크로드
• 시스템 : 워크로드가 바뀌면 동작패턴도 바뀐다.
• 네트워크 : 워크로드가 바뀌면 네트워크 패턴도 바뀐다.
• API : 워크로드가 바뀌면 API 패턴도 함께 바뀐다.

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



다양한 솔루션들이 존재한다.
 
• 대부분의 솔루션들이 eBPF 기반으로 동작
• 우리는 악성행위를 Alerting 도 해주고 Blocking도 해준다 ! 라고 한다.

• eBPF ?



: 리눅스 커널에서 실행되는 플그램을 위한 확장 가능한 프로그래밍 인터페이스
• 초기에는 네트워크 분석 및 패킷 필터링을 위해서 사용되었음
• 현재는 다양한 용도로 확장됨

• 시스템 레벨에서의 보안 정책
런타임 시큐리티로 넘어가면 low level에서 볼줄 알아야한다.
어떤 시스템 콜에 어떤 파라미터 값이 들어오면 alert을 해라..

• 기본적으로 보안 정책들은 비정상적 상황을 탐지했을때 컨테이너 킬, 프로세스 킬, 등등 이러한 조치가 들어간다.

• kill=서비스 중단 (Service Downtime)

• 공격자입장에서도 이런 액션을 지속적으로 해서 서비스를 중단시키지 않을까?

• 상용 제품은 오픈소스SW 보다 좋을까?
→ 결국 죽이는 행위이다 (컨테이너를)

• Post-Exploit Mitigation
: 공격을 탐지하고 나서 공격 차단을 시도 !
→ 공격자에게 너무 많은 시간을 준다.

• 대안은? Inline Mitigation



→ 공격을 탐지하자마자 차단

• Inline Mitigation 어떻게 동작하는지



• 탐지
• 프로세스 실행
• 파일 접근
• 네트워크 통신
• 시스템 콜 호출
• LSM Hook + eBPF 을 통해 디테일한 monitor 가능

네트워크 ?

• 네트워크 레벨에서의 워크로드 보안
• iptables 기반이라면 ?
검증이 안된다. 일일히 라인별로 보면서 검증이 쉽지 안핟.
• eBPF 기반이라면?
패킷 파싱해서 매칭.

API

• 시스템 레벨이나 네트워크 는 그나마 단순한 구조

• API 레벨에선 훨씬 더 구체적인 구조

• API 보안은 서비스 메시 와 밀접
why? : 마이크로서비스 간 통신 시 API 활용

• 같은 API라도 누가 사용하느냐가 중요
• 관리자냐 사용자냐에 따라 정책이 달라짐

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





• Istio
• Linkerd
이런 툴들에서 로깅을 해준다
그런데 URL 메서드 부분에 와일드카드(*) 가 낀다.
너무 복잡해진다.
 

• 그래서 user-space 의 Proxy를 사용한다.

• 결국은 유저레벨로 가야함.
 

7. QnA

• 데보션에 세션 발표자료 따로 올림.

• TKS 솔루션 관련 질문들.