6주차 - Security - EKS 인증/인가, IRSA, Pod Identity, Secrets Mgmt, Kyverno

0. 도입

K8S 인증/인가에 대해서 알아본다
AWS 인증/인가에 대해서 알아본다
EKS IRSA & pod Identity에 대해 알아본다.
Kyverno에 대해 알아본다.
EKS 워크숍 보안 솔루션에 대한 내용을 확인한다.
파드와 컨테이너의 보안 컨텍스트에 대해 확인한다.
실제로 탈취를 해보면서 어떤 부분이 취약한지 이해한다.
AWS내의 EKS 의 BEST PRACTICE를 알아본다.
혼자 알아낼려고했다면 너무나 많은 시간이 걸렸을 텐데 운영에 바로 적용할 수 있도록 이렇게 정리해주셔서 @Cloudnet팀 구성원분들께 감사합니다.
이번 주의 강의가 실무중에 생기는 보안적 취약점들을 점검할 수 있도록 케이스들을 알려주시고 대응방안을 말씀해주셨다. 4주차도 너무 유익했는데 6주차도 바로 사용할 수 있습니다.

1. 선수지식

필요 지식 : Service Account Token Volume Projection, Admission Control, JWT(JSON Web Token), OIDC
K8S 인증/인가
AWS 인증/인가

2. 실습 환경 배포

이번 환경은 DEVOPS 유저가 두명이라고 생각하고 BASTION 호스트가 2개이다
- 권한에 따른 접속 불가를 확인하기 위한 용도
이외에 특이사항은 없다.
GRAFANA 와 KUBEOPSVIEW 배포 확

3. K8S 인증/ 인가

A. [이론] K8S(API 접근) 인증/인가 소개

k8s 에서 요청은인증 -> 인가 -> Admission Controller에게 전달 되고 etcd에 마지막으로 저장됩니다.

인증

k8s에서의 인증은 HTTP Auth 나, kubectl의 .kubeconfig 를 통해 context에 저장되어있는 키를 통해 관리 가능합니다.
Service Account는 Secret을 가지게 되고 기본적인 사용자라고 생각하시면 됩니다.

인가

다음과 같이 인가 방식이 RBAC, ABAC, Webhook, Node 방식이 있습니다.
- RBAC는 Role Based Account Access 로 역할 기반의 권한 관리로 생각하면 됩니다.
- Role(역할) -> 어떤 리소스에 대한 권한 명시
- Service Account -> 유저
- Role Binding -> 롤과 SA를 맵핑을 명시
.kube/config
- clusters -> 원격 K8S API 서버 주소
- users -> 쿠버네티스 사용자 인증 정보 목록 (SA의 토큰, 인증서)
- contexts -> cluster + user 로 인증해 사용한다 라는 컨텍스트를 명시

B. [실습] 네임스페이스와 서비스 어카운트 생성/ 파드 생성후 권한 테스트

목적: 다른 권한을 가진 서비스 어카운트를 생성후에 권한 테스트

실험 설정:

위의 그림과 같이 SA 생성
파드 생성 이후에 특정 권한을 가지고 KUBECTL 실행 시 실행 확인

실험 결과:

서비스 어카운트 생성확인

다른 권한을 가진 SA에서 다른 POD에 대해서는 명령 내리지 못하는 것을 확인

C. [실습] 서비스 어카운트를 지정하여 생성한 파드에서 다시 권한 테스트

목적: SA 따른 파드 권한테스트

배경 지식:

롤이란: 리소스에 대한 VERBS 권한

실험 설정:

롤(Role)를 생성 후 서비스 어카운트 바인딩

실험 결과:

DEV 팀 ROLE 생성

ROLE BINDING 생성

Role binding에 대한 확인

특정 권한 가진것을 확인

4. EKS 인증/ 인가

A. [이론] EKS 인증/인가 큰그림

인증은 AWS IAM이 진행
인가는 K8S RBAC에서 진행

B. [실습] RBAC 관련 KREW 플러그인

해당 플러그인은 RBAC의 구성요소들을 쉽게 볼 수 있게 리스트업 해줍니다.
`kubectl krew install access-matrix rbac-tool rbac-view rolesum whoami` 으로 RBAC을 설치합니다.

다음과 같은 ROLE 에대한 정보들이 시각화 됩니다.

C. [이론] 인증/인가 완벽 분석 해보기

kubectl 에 요청을 보냄
AWS-IAM-Authenticator를 거쳐 AWS STS에 토큰을 요청
EKS API Cluster가 해당 토큰을 받아서 STS getCallerIdentity로 AWS IAM 인증 완료 후에 USER/ROLE에 대한 ARN 반환
해당 USER/ROLE 에 대해서 aws-auth configmap 에 mapping 정보 확인
k8s 인가 확인하고 동작 실행

-> 두개의 플랫폼과 인증과 인가가 되는 과정이 굉장히 복잡

-> 또한, config맵에 대한 의존성으로 AWS-AUTH CONFIGMAP을 잘못 수정시에 권한 오류로 장애가 생김

이 때문에, A deepdive into simplified Amazon EKS access Management controls 라는 신기능이 도입됨.

EKS 인증과 인가가 EKS 관련 Policy와 AWS 리소스에 대한 방법으로 통합됨 API를 우선하게 되고 API 로 변경시 CONFIG 롤백 되지 않음(주의!!)

다음과 같은 RESOURCE에 대한 POLICY로 통합됨

D. [실습] 데브옵스 신입 사원을 위한 myeks-bastion-2에 설정 해보기

목적: 실제로 유저를 하나 생성해서 권한을 RBAC으로 생성해서 K8S 동작 확인

배경 지식:

실험 설정:

TEST USER 생성
TEST USER 자격증명 설정
TEST USER 권한 설정

실험 결과:

KUBECTL 사용 확인
IAM mapping 삭제 후에 kubectl 사용 확인

Bastion 2 에서 정상 동작 확인

eks에서 iamidentity 맵핑 삭제 이후에 bastion2 에서 kubectl 동작 실패 확인

E. [실습] EC2 INSTANCE PROFILE에 맵핑된 K8S RBAC 확인

목적: 실제로 유저를 하나 생성해서 권한을 RBAC으로 생성해서 K8S 동작 확인

실험 설정:

노드 mapRoles 확인
파드 생성
config 맵 정보 확인

실험 결과:

생성된 파드로 노드에 대한 정보들 생성
해당 프로필을 사용하게되면 취약한 점을 알수있다.
1. 해당 토큰을 가져와서 모든 요청에 사용할 수있다!

E. [실습] [신기능] simplified Amazon EKS access management controls

목적: CONFIG가 아닌 API를 사용한 인증 인가 플로우 확인

실험 설정:

API 설정 생성 (CONFIG 무시)
테스트 유저 생성 및 정책 할당

실험 결과:

테스트 유저의 할당 으로 정상적 KUBECTL 명령 수행

5. EKS IRSA & Pod Identity

A. [이론] IRSA 소개

다음과 같이 EC2 Instanace Profile은인스턴스에 권한을 부여하여 사용하기 편함
하지만, 노드당 권한이 부여되어 하나의 파드가 탈취당하면 노드에 부여된 모든 권한을 사용가능
보안상 취약점으로 대두
이 때문에 IRSA가 파드에 대해서 권한을 부여하는 방법으로 권장됨

IRSA란? (IAM ROLES FOR SERVICE ACCOUNTS)
- pod 마다 권한을 가질 수 있게끔 할당하는것

IRSA의 동작 원리
- 파드가 토큰을 aws에 전송하고 aws는 토큰을 EKS ldP으로 IAM 권한검증

IRSA의고충
- 불편함;
  - 파드마다 생성 필요
  - 신규 클러스터 신뢰 정책 전부 수정 필요

POD Identity 라는 신기능을 도입

` Amazon EKS Pod Identity Agent ADD-ON 만 추가하면 Agent가인 token을 받아서 인증/인가를 확인할 수 있다.
SA 에 대해서 Pod Identity Association만 연결해주면 해당 SA에 대해서 동일한 권한을 지닌 POD가 생긴다.
TAG에 따른 추가적 할당도 가능하다.

B. [실습] k8s 권한 없음 확인/ KSA를 사용해 S3 서비스 확인

목적:

배경 지식:

실험 설정:

API 설정으로 SA Token 설정 false로 변경

실험 결과:

access denied 확인

B. [실습] KSA 생성, 파드 생성 이후 토큰 탈취 당할 리스크 확인

목적: KSA 생성, 파드 생성 이후 토큰 탈취 당할 리스크 확인

실험 설정:

pod 생성
토큰 탈취 및 해당 토큰으로 서비스 사용

실험 결과:

토큰으로 확인 및 aws 서비스는 사용 되지 않는것은 확인
토큰 안의 페이로드들 확인

여기서 중요한것이 AWS는 토큰 변조만 확인해주는 것이라서 서비스 계정에 역할에 대해 신뢰 정책이 *로 되어 있다면 클러스터 내의 해당 계정들에 대한 모든 역할이 가능해진다.

예를 들면, 다음과 같이 설정하게 되면 자격들이 내려온다.

실습은 했으나 스크린샷 미첨부

A. [실습] EKS Pod Identity

목적: Identity를 사용해서 위에 생기는 취약점을 조치

실험 설정:

`ADDON=eks-pod-identity-agent aws eks describe-addon-versions --addon-name $ADDON --kubernetes-version 1.28 --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" --output text`
1. add on 설치
aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent
1. agent 설치
podidentityAssociation 생성