[Kubernetes] 쿠버네티스 / 앱 현대화 테크 세미나 후기 (2)

 

다음은, SKT 컨테이너 솔루션 개발팀 조동규님의 인증과 인가 소개입니다.

 

이후로, 임성일님, 남재현 교수님께서 Admission과 워크로드 보안 실사례까지 진행해주셨습니다.

 

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

SKT 컨테이너 솔루션 개발팀 조동규

OIDC 동적으로 쿠버네티스 접근 제어

• Authentication, Authrization까지

1. 쿠버네티스 접근 제어 방식
2. OIDC 제어
3. 그거에서 부족한거 TKS의 접근 제어 방식
4. 내부 기술 구성 간략히 짚어보기

Kubernetes 접근 제어하기

• 인프라운영자 - 쿠버 클러스터 관리
  • 쿠버 클러스터: 여러 종류 서비스 운영, 개발자가 kubectl로 접근하여 사용
  • 클러스터 관리자: 클러스터 안전 가장 우선
  • 개발자: 내 마음대로 무언가 하는 환경 필요
• Native 쿠버네티스 접근 제어 방식
  • 클러스터 관리자 : 문서 관리
  • kubeconfig: Cluster / User 정보를 묶어 높은 것입니다.
    • 클러스터: 클러스터 URL, 인증서
    • 유저는 토큰.
  • 현업에서 엑셀로 정리해서 문서 배포하고 설정도 그대로 적용함.
• 문서관리의 가장 어려운게, “최신화”시킨다. 문제.
• 2번째 문제: 토큰
  • 한번 발급한거 고정됨. → 그 토큰 회수하는게 현실적으론 불가능함.

OIDC를 활용한 쿠버네티스 접근 제어 방식

• 빨간 색 확인 (변화되는 부분)
• Auth Server 관리
  • OIDC: 중앙 인증 서버를 둬서 중앙 인증 서버로 부터 인증서버 받아와서 접근할 수 있게 하는 기술.
    • 사용자 정보가 중앙인증서버에서 관리가 된다.
  • 전체 정보를 AUth Server에서 관리합니다.
  • 정보 관리 툴이 좀 더 개선될 수 있습니다. 클러스터마다가 아니라 중앙 인증 서버에서만 관리하면 됩니다.
• OIDC 적용시, 다 동일한 쿠버콘피그합니다. 동적으로 토큰 받아오는 기술입니다. 동적으로 받아오니까 미리 기재할 필요 없이, 인증 서버 주소 (정보)만 적혀있습니다.
  • kubelogin plugin
  • browser가 중앙 인증 서버
  • 5번이 ID/PW 입력
  • 중앙인증서버에서 토큰 전달받는다.

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

• 시스템 까지 전부 관리할 수 있지 않을까?
• TKS UI를 통해 사용자, 역할, 권한 관리

개선 사항

1. Open ID Connect 기술 도입
   1. 중앙화된 신원 정보 관리
   2. 중앙 집중화된 인증
2. RBAC 설정 자동화 (UI 관리)

기술 구성

1. 인증
   1. 인증 개요
   2. JWT Token
   3. Open ID Connect(OIDC)
2. 인가
   1. 인가 개요
   2. Kubernetes

인증 (Authentication)

• 사용자가 서버에게 누구인지 증명하는 과정.
• 개인화된 서비스 제공 & 자원 보호

인증토큰: Json Web Token(JWT)

• 세션 ID만 아니고, 추가 정보 함께 전달 → 비밀키/공개키 등으로 → 넘기려는 정보를 한번 더 암호화하는 과정을 거친다.
• 서버는 특정 정보를 자신의 비밀키로 암호화한다.
• 암호화 정보를 토큰이라 불러서 전달하게 된다.
• 토큰을 던졌을 때, 서버에서 비밀키로 암호화한 걸 공개키로 복호화 → 정상, 원한 결과가 있으면 → 토큰 검증 성공.
  • aud: 나를 위한토큰이 맞는지 식별한다.
  • 이 정보로 페이로드 구성된다.
• Signature 서명
  • 헤더, 페이로드 인코딩 → 비밀키로 전자 서명하여 변조 방지.
  • 검증 용도.
• JWT 효과
  • 인증서버 발급한게 맞다/아니다 검증을 확실히 가져올 수 있다.

OpenID Connect

• 신원에 대한게 ID Token에 구현됨.
• 안에 필드 하나가 claim으로 합니다. 추가로 정의합니다.
• Custom Claim을 추가로 더 추가 가능해요.

인가(Authorization) : RBAC 내용

• 권한
  • 특정 사용자가, 특정 자원 작업 수행.
  • HTTP는 토큰 정보(주체), PATH variable, 행위는 HTTP 메소드(GET, POST 등)
  • 쿠버 예시
    • Role binding → roleref 자원과 행위 묶음
    • Role → rules: 자원 행위를 세부적 정의
• 인가: 주체를 의미
  • 앞에서 인증이 일어난 다음에, 인증의 신원 정보를 가지고 인가 하게 된다.

이를 위한 작업들

• 초기 설정
  • Auth Server: client → client-id, user role 값으로 넣기
  • 쿠버: 인증서버 설정
• 관리
  • Auth Server: 사용자 마다 역할을 계속 매핑시켜줘야 한다.
    • client와 role 매핑 관리
  • 쿠버: 역할, 권한 바뀔때마다 지속적으로 작업해줘야 한다.

→ TKS Backend 자동화

나머지는 관리자가 TKS Console을 통해 작업

• 역할별 Custom 권한 설정 → 추가 예정

 

 

자동화된 정책으로 클라우드 보안 및 운영 강화하기

 

SKT 임성일

Kubernetes에게 “Policy” 이란? + TKS Cloud Service

자동화된 정책으로 클라우드 보안 및 운영 강화하기

 

Kubernetes 정책 관리

• 인증과 인가를 넘어서
  • 정책
  • 정책은 인가 포함 더 넓은 범위.
  • 정책은 정확히 정의하기 어렵다. 거버넌스의 일부이면서, 인가 자체를 포함하고 자체의 무언가입니다.
  • 권한 놓고 동일하게 부여한다. role 하나도 개별 처리할 수 있음.
  • API 접근에 가/부 외에 함께 전달된 파라미터, 컨텍스트에 의해서 허용할지 말지 결정할 필요 있다.
• 쿠버의 정책 관련 지원 기능
  • RBAC, PSP(파드별 권한 부여 Pod Security Policies),
  • Network Policy(네트워크 트래픽 제한), Admission Policy(CEL 언어로 규정)
• Kubernetes Admission Controller
• 쿠버네티스용 정책관리 도구
  • 카이버노, OPA 게이트 키퍼, OPA, Istio도 있음.
• 정책관리별 장단점 비교
  • Gatekeeper
  • kyverno
    • 간단. 별도 웹훅 구성. 게이트키퍼보다 제한된 정책정의한다.
  • PSS/PSA
  • Admission Policy (신규, 최신)
    • 장점을 잘 흡수한 것임.(게이트키퍼, 카이버노)
• [참고] gatekeeper 사용예, kyverno 사용예 (Rule 따라 정의), PSA 예시(클러스터 수준 중의, 네임스페이스 수준 정의)
  • +Validating Admission Policy 사용예

기반기술들: OPA, Rego, Gatekeeper

1. OPA(Open Policy Agent)

전용언어로 로직 정의

정책 평가 위한 컨텍스트 입력으로 전달. 컨텍스트를 통해 판별함.

서비스 형태로 들어와서, 내부/외부 저장소 연결하여 동작함.

 

2. Policy as Code

• 장점
  • 정확성, 투명성 향상, 재사용, 검증/테스트
  • 버전관리, 저장소
  • 코드 개발에서 사용하던 협업 툴 활용 가능

Gatekeeper(1/2)

• 최근 Mutation 지원
• 구성요소: Controller, Auditor
• 인프라 위에 쿠버네티스
• 정책정의, 클러스터 정의
• 데브옵스 엔지니어가 그 클러스터로 사용.

정책스케쥴러

• 다중클러스터 지원 이슈
• TACO LMA

정책 스케쥴러 사용자 자원

• TKSCluster
• TKSPolicyTemplate
• TKSPolicy
  • Gatekeeper 콘스트레인트의 다중 클러스터 지원확장버전.

실효성 있는 정책템플릿 제공 (1/2)

TKS Policy Demo (1/3)

• 다양한 정책의 템플릿 제공
• 조직 관리자는 구체적인 파라미터를 지정하여 정책 생성.
• 개발자는 별도 관여없이 자유 배포, 오류 발생시 정책 위반을 인지하여 수정 후 배포

Gatekeeper 설정

• 삭제에 대한 audit 추가 enableDeleteOperations
  • 자원 삭제는 기본적으로 audit 하지 않음.
• 정책위반으로 거분 내역에 대해 로그 기록

Custom controller 개발

• 초기에 CR 잘 정의하라
  • 스펙, 스테이터스 명확히 나누기
  • 외부에서는 Spec 영역 변경
  • Reconcile 내부에서는 Status 영역 변경
• Reconcile loop 내부 대상 CR에 대한 변경 “한번만” 수행
• 멱등성 고려
• Cluster 범위 넘어서 접근에 따른 제약 확인
• Finalizer 처리

PolicyTemplate 작성 및 정책 적용

• 매치절도 잘 써요.

다음 단계

• 내부연동도 쉽진 않은데
• GateKeeper 엔진
• LLM 연동 Template Scaffold 생성해보고 싶어요.?
• 정책 카탈로그 예쁘게 한다.

TKS Policy 교육 준비 중.

• 6월 중 예정, REGO 문법/정책작성 실습 / 정책의 적용 및 활용 방법.

 

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

남재현 교수

쿠버네티스 워크로드 보안

 

일단! 클라우드 ‘워크로드’ 보안이 뭐지?

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

• 클러스터 내 실행되는 애플리케이션, 서비스 보호
• 어떻게 강화?
  • 네트워크 정책
  • Pod 보안 정책(PSP → PSS)
  • 서비스 계정
  • RBAC
  • 쿠버네티스 시크릿
  • Admission Controllers
• 사전 단계 시큐리티

런타임에서도 보안이 중요해요.

실시간으로 바뀌는 것?

• 워크로드(Workload): 실시간 생성/삭제
• 나비효과! (함께 바뀌는 것)
  • 시스템
  • 네트워크
  • API

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

eBPF: Extended 버클리 패킷 필터

시스템 레벨에서의 액션!

• 노티, 컨테이너 kill, 컨테이너 모든 프로세스 kill 등

상용제품은 오픈소스 SW보다 좋을까?

• 결국은 컨테이너를 Kill.

Post-Exploit Mitigation

• 공격을 탐지하고나서 → 공격 차단을 시도!
• 공격자에게 시간을 너무 많이 줌.
• 대안은? inline Mitigation! : 공격 시도자마자 차단

Inline Mitigation

• 공격을 탐지하자마자 차단
• ex) kubearmor

Inline-Mitigation 어떻게?

• 일단 탐지부터?
• 여기서 봐야할 것들?
  • 프로세스 실행, 파일 접근, 네트워크 통신, 시스템 콜 호출 등
  • ex) Tetragon
• 결과를 본다.
  • LSM Hook: 파라미터 값, 더 디테일한 값 본다.

차단은 어떻게?

• LSM hooks
• BPF-LSM

네트워크는 어떻게?

• 네트워크 레벨에서의 워크로드 보안
  • Calico : BGP 기반 라우팅
  • Cilium : eBPF

1. Calico 네트워크 정책
   1. 통신 누구랑 하는지 알려달라.
2. Cilium

네트워크 레벨에서의 워크로드 보안

Policy Discovery Engine

네트워크 정책은 어떻게 적용하지?

네트워크 레벨에서의 워크로드 보안

• iptables 기반이라면?
  • 너무나 많은 룰을 만든다. 근데, 검증이 안된다.
• eBPF 기반이라면?
  • 1. Packet을 하나하나 디코딩해서 결국 보안 정책과 매칭!
  • eBPF 쓸 때 좋은점?

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

로깅하고 자연스럽게 차단하면 된다.

• API를 표현하는 방법
  • 정규표현식, 구글의 RE2 사용(ISTIO)
  • 이건 너무 복잡해요.
• 결국은 User 레벨로 가야한다. 유저 스페이스의 Proxy를 사용한다.
  • goggle’s RE2
  • 패킷이 나가는 순간 커널 내려감.
  • 거기에 정규식 매칭. 좋은데 성능은 보장할 수 없다.
  • API 시큐리티 잘 적용 안됨. 문제 발생.

이제 마무리 해봅시다.

워크로드 보안 마무리

• 쿠버네티스 환경에서 다양한 워크로드 보안 솔루션 존재
• 시/네/API레벨 보안 솔루션 필요 → 너무 어려워요.?
  • 개발팀도 몰라요. 복잡해.
• 런타임 워크로드 보안을 잘 할 수 있어요.

 

나의 후기 및 마무리: 쿠버네티스 보안의 미래는?

쿠버네티스 보안이라고 하면 어렵고 딱딱한 건 어쩔 수 없는 것 같습니다. 현업에서 적용하는 것도 "쉽지 않다"는 결론이 나다보니, 결국 자동화된 도구를 적극 사용하는 것을 권장하는 걸로 마무리하는 걸 보면서 더욱 강하게 느꼈습니다. 보안은 아직도 어려운 상황임을 확실하게 깨달았습니다. 다양한 도구가 넘쳐나는 것은 그만큼 확실한 무언가가 만들어지지 않은 거라 보고, 이 시장에 진입할 좋은 기회로 삼아 보안에 대해 공부하려고 합니다.

마지막으로, 한기호님의 멘트가 기억에 남았습니다.

"보안은 어렵고, 규칙도 많아지고 돈도 많이 들고 힘듭니다. 한번 이해 해봅시다. 공사장에 이런 개념이 있다. 이사람이 저기 가도 위험, 반대로 가도 위험해요. 그런데 이 사람은 줄을 감아 두면, 어디를 가도 위험에 빠지지 않고 줄 안에서 자유롭게 돌아다녀도 됩니다. 마찬가지로, 쿠버네티스도 보안 정책(Policy)을 잘 작성해주면, 어렵지 않고 안전하게 작업을 진행할 수 있습니다."

보안의 매력이 이런게 아닐까요? 거버넌스라는 개념으로 설명해주셨지만, 결국 권한 정책을 잘 짜두면 개발자가 "본인도 모르게" 보안에 위협을 주는 행동을 할 이유가 없습니다. 그냥 개발을 하다가, 보안적으로 문제 있는 작업은 권한이 없어 진행이 안되겠죠. 에러 메시지가 뜨거나 접근이 안되는 형태로 나타날 겁니다. 그러한 약속을 통해, 그 안에서 자유롭게 개발을 하더라도 보안에 문제가 되지 않는 것이 궁극적인 쿠버네티스 보안의 목표가 아닐까 싶습니다.

DevOps를 넘어서 이제는 "DevSecOps"라는 개념이 나오고 있습니다. 클라우드 엔지니어로서 도전할 새로운 커리어 목표를 설정하고, 쿠버네티스 개념에 보안을 더해 성장해보겠습니다.