🛴목표

보안은 시스템 구성에서 운영까지 가장 중요하게 생각되는 부분 중 하나이다. 쿠버네티스에서도 보안은 빠질 수 없는 중요한 부분이다. 어떻게 안전하게 클러스터를 구성해야 하는지, 어플리케이션을 컨테이너 환경에서 안전하게 운영할 지, 취약점 점검은 어떻게 하며, 어떠한 솔루션을 사용하는지 이번 7주차 마지막 스터디에서 학습 할 예정이다.

EC2 IAM Role & 메타데이터

KOPS는 AWS EC2 Instance(Node)를 클러스터로 구성한다. 해당 Instance에 배포된 Pod는 Instance에 부여된 IAM Role를 그대로 사용할 수 있다. 이러한 경우 해커에 의해 Pod하나가 공격을 받아 탈취를 당하게 되면 Instance의 IAM Role를 그대로 탈취하게 되는 상황이 발생한다. 따라서 보안적으로 매우 취약한 모습이다.
위 그림의 빨간 박스가 Instance의 IAM Role를 배포된 Pod가 그대로 부여받은 취약한 모습을 나타낸다.

IRSA(IAM Roles for Service Accounts)
이러한 취약점 때문에 Pod별 IAM Role를 부여하여 해당 Pod가 탈취를 당해도 다른 Pod 및 Instance에 권한이 없도록 구성하는 방식으로 현재는 EKS, KOPS 최신 버전은 안전하게 클러스터를 구성하고 있다.
위 그림의 파란색 박스가 Pod별 IAM Role를 적용한 모습을 나타낸다.

메타데이터 보안제거 실습

#현재 클러스터 인스턴스 및 인스턴스그룹 정보

#ap-northeast-2a, ap-northeast-2c의 인스턴스 메타데이터 보호 설정 정보

#이 중 ap-northeast-2a의 메타데이터 보호 설정 정보 제거

#Pod 두 개가 Node 별로 한개 씩 배포(netshoot-pod)

#이 중 Pod1번이 메타데이터 보호 설정이 제거되어 있는 Instance에 배포되어 있음

#파드1에서 EC2 메타데이터 정보 확인(Token 정보 확인!)

#Pod2에서는 EC2 메타데이터 정보를 확인 할 수 없음 / 인스턴스 메타데이터 보호 설정이 되어 있기 때문에!!

1. SDK 사용을 위한 python pod 배포(boto3)

cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: boto3-pod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: boto3
  template:
    metadata:
      labels:
        app: boto3
    spec:
      containers:
      - name: boto3
        image: jpbarto/boto3
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

2. boto3 Pod 확인(PODNAME1이 ap-northeast-2a의 instance에 배포)
   
3. pod1에 접속 후 인스턴스 정보를 출력하는 python 코드 작성 후 실행(Instance의 정보 출력)

kubectl exec -it $PODNAME1 -- sh
-----------------------------
cat <<EOF> ec2.py
import boto3

ec2 = boto3.client('ec2', region_name = 'ap-northeast-2')
response = ec2.describe_instances()
print(response)
EOF
-------------------
python ec2.py

4. Pod2에서는 boto3 실행이 안됨
   

[실습내용 정리]
boto3는 Python용 AWS SDK를 말한다. 이 boto3를 사용하기 위해서는 AWS 자격 증명이 필요하다.
위 실습에서 boto3는 AWS의 자격증명을, 즉 IAM 역할이 구성된 EC2 Instance의 인스턴스 메타 데이터를 사용하여 boto3를 사용할 수 있었던 것이다. 다시 말해 인스턴스의 메타 데이터를 탈취하면 해당 정보를 통해 sdk를 사용할 수 있으며, 이는 AWS 콘솔에서 할 수 있는 모든 행위를 sdk를 통해 제어 할 수 있다는 것을 의미한다.... 무서움..!!!!🥶🥶
(출처: https://tech.cloud.nongshim.co.kr/2021/03/12/boto3%EA%B0%80-aws%EC%9D%98-%EC%9E%90%EA%B2%A9%EC%A6%9D%EB%AA%85credentials%EC%9D%84-%ED%99%95%EC%9D%B8%ED%95%98%EB%8A%94-%EC%88%9C%EC%84%9C-from-python/)

취약점 점검(kubescape / polaris)

kubescape

미국 NSA(National Security Agency) / CISA(Cybersecurity and Infrastructure Security Agency)에서 발행한 쿠버네티스 보안 체크리스트를 기준으로 현재 쿠버네티스 클러스터의 취약점을 점검하고, 이를 대시보드 형태로 리포팅을 하는 취약점 점검 툴이다. 또한 코드,CI/CD pipelines등의 취약점 점검도 가능
(출처: https://github.com/kubescape/kubescape)

# 설치
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Download all artifacts and save them in the default path (~/.kubescape)
kubescape download artifacts
tree ~/.kubescape/
cat ~/.kubescape/attack-tracks.json | jq

# 제공하는 보안 프레임워크 확인
kubescape list frameworks --format json | jq '.[]'
"AllControls"
"ArmoBest"
"DevOpsBest"
"MITRE"
"NSA"
"cis-eks-t1.2.0"
"cis-v1.23-t1.0.1"

# 제공하는 통제 정책 확인
kubescape list controls

# 클러스터 스캔
kubescape scan --enable-host-scan --verbose

• 각 노드에 kubescape pod가 생성되고 해당 Pod가 노드의 취약점 점검을 진행 / 진행이 완료되면 자동으로 Pod가 삭제
  

• 설치 후 클러스터 스캔 화면
  

polaris

오픈소스 쿠버네티스 클러스터 및 코드 취약점 점검 툴 / 쿠버네티스 리소스 배포 시 취약점이 있다면 배포를 못하게 제어(Admission Request -> Validating Webhook)
(출처: https://github.com/FairwindsOps/polaris)

# 설치
kubectl create ns polaris

#
cat <<EOT > polaris-values.yaml
dashboard:
  replicas: 1
  service:
    type: LoadBalancer
EOT

# 배포
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install polaris fairwinds-stable/polaris --namespace polaris --version 5.7.2 -f polaris-values.yaml

# CLB에 ExternanDNS 로 도메인 연결
kubectl annotate service polaris-dashboard "external-dns.alpha.kubernetes.io/hostname=polaris.$KOPS_CLUSTER_NAME" -n polaris

# 웹 접속 주소 확인 및 접속
echo -e "Polaris Web URL = http://polaris.$KOPS_CLUSTER_NAME"

• 웹 화면
  
  Namespace: default / Deployment: netshoot-pod
• Dangerous checks

취약점 조취

• image태그 명시
• Liveness probe 명시

#netshoot-pod 에 보안 모범 사례 적용

cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-pod
spec:
  replicas: 2    // pod 수
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot-pod
        image: nicolaka/netshoot:v0.9  // 이미지 태그
        command: ["tail"]
        args: ["-f", "/dev/null"]
        imagePullPolicy: Always       // 이미지 항상 pull
        resources:                    // 리소스 관련 제한
          limits:
            cpu: 150m
            memory: 512Mi
          requests:
            cpu: 100m
            memory: 128Mi
        securityContext:            //securityContext
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          privileged: false
          readOnlyRootFilesystem: true
          #runAsNonRoot: true
      terminationGracePeriodSeconds: 0
EOF

webhook 실습

1. webhook 설정( --set webhook.enable=true)

# webhook 활성화 적용

helm upgrade polaris fairwinds-stable/polaris --namespace polaris --version 5.7.2 --reuse-values --set webhook.enable=true 

kubectl get pod,svc -n polaris

2. 취약점 있는 Pod 배포

cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-pod
spec:
  replicas: 1               //replicas가1이면 취약점으로 판단
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot-pod
        image: nicolaka/netshoot  //이미지의 태그 미설정
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

3. 확인
   
   취약점의 이유로 Pod 배포 실패!!!!!!!

K8S 인증/인가 & RBAC

인증(authentication): 사용자에 대한 확인으로 정상적인 사용자 인지를 확인하고 제어 하는 것(출처: https://kubetm.github.io/k8s/07-intermediate-basic-resource/authentication/)

인가(authorization): 인증을 거친 사용자가 인가된 행위를 하는지 확인하고 제어 하는 것(출처: https://kubetm.github.io/k8s/07-intermediate-basic-resource/authentication/)

처음 쿠버네티스를 접했을 때, 클러스터를 kubeadm으로 구성하였다.
구성을 하고 나면, kubectl 명령어를 통해 모든 기능을 사용 할 수 있었다. 즉 API를 통해 제공하는 모든 기능을 사용 할 수 있었다.
아무생각없이 사용을 했지만, 이는 사실 리눅스의 Root 계정과 동일하게 admin 권한을 가지고, API를 사용하고 있었던 것이다.

#.kube/config 파일 확인

• context 정보 및 사용자 인증서 정보
  
• kubectl config view 정보
  

사용자는 burst89.com / context는 bursti89.com으로 관련된 인증서가 config파일에 저장되어 클러스터 api를 사용할 수 있었다.

쿠버네티스는 이러한 인증(인증서 / kubectl / SubAccount) 및인가(RBAC(Role Based Aceess Control))으로 구현되었다.

쿠버네티스에서는 리눅스처럼 사용자 별로 특정 권한을 제한하는 사용자 계정을 생성 할 수 있고, 계정에 따라 특정 네임스페이스에만 실행을 제한하거나, 특정 실행 기능만 동작 할 수 있게 지정 할 수 있다.

이번 실습에서는 역할 기반 접근 제어를 통해 특정 네임스페이스에 대해서만 권한을 가지는 사용자를 생성하여 쿠버네티스의 인증/인가를 살펴보자!!

1. dev / infra 네임스페이스 생성
   
2. dev / infra SubAccount 생성 및 확인
   

3. 네임스페이별 사용 가능한 kubectl Pod 배포

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: dev-kubectl
  namespace: dev-team
spec:
  serviceAccountName: dev-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.24.10
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: infra-kubectl
  namespace: infra-team
spec:
  serviceAccountName: infra-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.24.10
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

4. Pod 확인
   
5. 인증서/토큰/네임스페이트 정보 확인
   
6. 사용 편의를 위해 Alias 지정

alias k1='kubectl exec -it dev-kubectl -n dev-team -- kubectl'
alias k2='kubectl exec -it infra-kubectl -n infra-team -- kubectl'

7. 권한 확인(현재 Role이 바인딩 되어 있지 않아, 어떠한 명령어도 실행할 수 없는, 권한이 없는 상황)
   

8. Role 생성 및 롤 바인딩

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-dev-team
  namespace: dev-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-infra-team
  namespace: infra-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

# 롤바인딩 생성 : '서비스어카운트 <-> 롤' 간 서로 연동
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-dev-team
  namespace: dev-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-dev-team
subjects:
- kind: ServiceAccount
  name: dev-k8s
  namespace: dev-team
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-infra-team
  namespace: infra-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-infra-team
subjects:
- kind: ServiceAccount
  name: infra-k8s
  namespace: infra-team
EOF

9. 롤 바인딩 확인
   

10. 확인(각 get pods 명령어를 사용하여 현재 배포된 Pod의 정보 출력)
    

---

[과제1] 파드에서 EC2 메타데이터의 IAM Role 토큰 정보를 활용하여(boto3), 스터디에서 소개한 것 이외의 다른 AWS 서비스(혹은 Action)를 사용 후 코드나 스샷을 올려주세요
1. AdminAccessRole 추가

2. 실습때 사용한 Polaris LB를 boto3를 사용하여 삭제!

• 현재 CLB 정보(clb name: a541ce16a8d874a53830b763c89ce9e0)

• boto3 CLB 삭제 스크립트 작성
  boto3 lb정보 링크:
  https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elb/client/delete_load_balancer.html

import boto3

client = boto3.client('elb',
                       region_name = 'ap-northeast-2',
                       )

response = client.delete_load_balancer(
    LoadBalancerName='a541ce16a8d874a53830b763c89ce9e0'
)
print(response)

3. 실행화면

4. service 확인 및 aws console LB 확인
   
   LB가 정상적으로 삭제는 되었지만, 쿠버네티스 클러스터 정보에는 강제 삭제한 내용이 적용되지는 않아 계속해서 로드벨런스가 존재하는거 처럼 정보 표시!!
   

[과제2] 책 398~400페이지 - kubescape armo 웹 사용 후 관련 스샷을 올려주세요
1. cloud.armosec.io 회원 가입 Dashboard 설정

• 설치

• 대쉬보드 확인

[과제3] polaris 관련 실습(아무거나) 후 관련 스샷을 올려주세요
1. 기존 실습에 사용했던 마리오 Deployment 생성 후 polaris 확인
2. 취약점 조취 후 확인
3. 변경된 yaml파일

[과제4] 신규 서비스 어카운트(SA) 생성 후 '클러스터 수준(모든 네임스페이스 포함)에서 읽기 전용'의 권한을 주고 테스트 후 코드나 스샷을 올려주세요

1. secure-team 네임스페이스 생성 및 secure-k8s SA 생성
   
2. secure-team 네임스페이스에 kubectl Pod 배포
   
3. 클러스터 롤 생성 및 클러스터 롤 바인딩(읽기 권한)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secure
rules:
- apiGroups: [""]
  resources: [""]
  verbs: ["get", "watch", "list"]

#kubectl 명령어로 clusterrole 생성!
k create clusterrole secure --verb=list --verb=get --verb=watch --resource=*

  apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: crb
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: secure
subjects:
- kind: ServiceAccount
  name: secure-k8s
  namespace: secure-team

#kubectl 명령어로 clusterrolebinding 생성!
k create clusterrolebinding crb --clusterrole=secure --serviceaccount=secure-team:secure-k8s

5. Aliase 설정

alias k3='kubectl exec -it secure-kubectl -n secure-team -- kubectl'

6. 모든 네임스페이스에서 pod 정보 출력 가능 확인
   
7. Pod의 생성은 불가능(get, list, watch만 가능)
   #secre-team 네임스페이스에서도, default 네임스페이스에서도 pod 생성 불가능!!
   

마무리

이번 7주차 마지막 스터디에서는 쿠버네티스의 보안에 대해서 학습하였다. 보안은 중요한 부분이면서도 어려워서 보통 전체 카테고리 중에서 마지막에 소개를 한다. 우리 스터디도 마지막 스터디에 보안에 대해서 배우게 되었다. 클러스터의 취약점 점검, 인스턴스와 Pod별 권한 분리(IRSA)의 중요성을 직접 확인 할 수 있었다. 또한 계정(SubAccount/namespace)를 구분하여 클러스터를 구성하는 환경도 실습해 보았다. 실제 쿠버네티스 운영 시 이러한 부분은 기본중에서도 기본이 될거 같아서 마지막 학습도 많은 도움이 되었다고 생각이 든다.

아직 실무에서 쿠버네티스 서비스를 사용하지 않아, 잘은 모르지만 스터디에서 배운 내용과 정훈님의 책에서 배운 내용이 실무에서 많은 도움이 될거 같다!!!

짧다면 짧은 기간이였지만 4주동안 스터디를 따라가는게 쉽지는 않았다. 기초지식이 부족하고, AWS 지식도 부족하여 스터디를 따라가는데 많이 힘든 부분도 있었다. 그래도 이렇게 마지막 수업까지 듣고 과제를 제출할 수 있어서 영광으로 생각한다.

가시다님, 24단계 실습으로 정복하는 쿠버네티스 저자 이정훈 님께 다시한번 감사의 말씀을 전합니다!!!!!

🐱‍👓