AEWS 6주차. EKS security - 실습

1단계. RBAC 관련 krew 플러그인

  - access-matrix : 서비스 리소스별 RBAC access 정보 확인 

  - rbac-tool : rbac 관련 lookup, whoami policy-rules 등 여러가지 확인 기능 제공

  - rbac-view : 웹을 통해 Cluster Roles와 Roles를 확인

  - rolesum : 사용자, Service Account별 RBAC 역할에 대해 간략하게 요약 정리

 

※ 2/3단계 참고

 

2단계 : 인증 과정 따라가기 

  - kubectl 관련 임시자격 토큰 요청 확인 : ~./kube/config 파일 내에 user 부분에서 요청 확인

    : eks get-token --output json --cluster-name myeks --region ap-northeast-2

  - token 요청 및 발급된 token 내용 확인

    : 요청시 cloudtrail에 해당 로그 기록

  - 해당 토큰은 Pre-signed URL임으로 디코딩해서 내용 확인

https://sts.ap-northeast-2.amazonaws.com/?
Action=GetCallerIdentity
Version=2011-06-15
X-Amz-Algorithm=AWS4-HMAC-SHA256
X-Amz-Credential=AKIAYUHA6R52ALFFZCOU/20230603/ap-northeast-2/sts/aws4_request
X-Amz-Date=20230603T075106Z&X-Amz-Expires=60
X-Amz-SignedHeaders=host;x-k8s-aws-id
X-Amz-Signature=9e3cd7412d3b4e.............

   - k8s API 서버는 webhook을 통해 IAM에 인증 요청

  - Tokenreview : 사용자에 대한 토큰 인증을 수행, webhook token authenticator 플러그인에 위해 k8s apiserver에 캐쉬됨

    : webhook token authenticator로 AWS IAM Authenticator를 사용

  - kubectl 관련 요청시 사용자를 기반으로 IAM 인증

- GetCallerIdentity 관련 사항은 CloudTrail에서도 확인 가능

 

3단계 : 인가 과정 따라가기

  - k8s 내부 인증을 통한 RBAC 처리 : IAM User/Role이 확인되면 AWS-Auth configmap에서 mapping 정보 확인

    : whoami 에서 확인되는 system:masters 그룹에 대한 정보가 없음 -> 보안상의 목적으로 숨김 처리(삭제 방지)

  - system:master는 Cluster-admin과 매핑

    : Cluster-admin은 모든 권한을 보유

 

4단계. 신규사용자 만들기

  - 신규사용자용 IAM 사용자 및 Access Key 생성 : testuser

  - 해당 계정에 정책을 추가

  - get-caller-identity 확인 : 가능

  - 신규 생성한 계정으로 다른 Bastion에서 동일 쿼리 수행 확인 후 kubectl 확인

    : ~/.kube 내 인증 관련 설정 파일이 없어 실패

  - IAM identity 매핑

    : testuser 에 system:master 그룹 부여 및 정상 매핑 여부 확인

  - .kube/config 파일 생성

  - kubectl 관련 명령어 수행 여부 확인

  - testuser의 그룹 변경

    : kubectl edit cm -n kube-system aws-auth //master -> authenticated

    : RBAC에서 권한 매핑 변경시 IAM에서는 정상이지만, master 권한은 RBAC에 의해 권한 차단

    : authenticated가 가진 권한은 수행 가능 : kubectl api-resources

  - IAM에서 testuesr 삭제

    : authenticated 관련 권한도 모두 삭제

    : auth-config에서 확인시 mapUsers 정보 삭제

 

5단계. EKS IRSA : 자동 Service Account용 Token 발급을 False로 한 상태에서 신규 pod 배포

  - s3의 파일을 확인하는 pod 생성

  - pod를 보면 Service Account는 Default지만, 관련된 Volume은 none인 상태 확인

  - pod Status도 Error이며, log 상태는 Access Denied

 

6단계. EKS IRSA : 자동 Service Account용 Token을 사용한 상태서 신규 pod 배포

  - pod를 보면 Service Account는 Default지만, 관련된 Volume이 생성됨을 확인

  - pod 상태 확인 후, AWS S3에 Service 접근 시도 : Access Deny

  - Service Account용 Token 및 해당 Token의 세부 정보 확

 

7단계. EKS IRSA : webhook을 통해 IRSA

  - Service Account, IAM Role, Trust Policy 생성

eksctl create iamserviceaccount \
  --name my-sa \
  --namespace default \
  --cluster $CLUSTER_NAME \
  --approve \
  --attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)

  - IRSA 생성시 마다 CloudFormation을 통해 IAM role 생성 확인

    : IAM role에 권한을 연결 및 Trust Policy 생성

    : Service Account에 Annotations 확인 

  - 생성된 ServiceAccount를 사용하는 신규 pod를 배포

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test3
spec:
  serviceAccountName: my-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
EOF

  - mutatingwebhook 설정을 확인

    : pod 생성시 별도의 환경변수를 넣지 않았음에도 mutating webhook에 의해 자동 추가

    : 신규 pod의 Environment 부분 확인 + Projected Volume 생성

  - pod에서 권한동작 정상 여부 확인

    : pod에서 AWS API 서버에 자신의 coller identity 확인

    : pod에서 S3 접근 확인

    : pod에서 EC2나 VPC는 접근 확인 : 불

  - pod에 mount된 볼륨 2개 확인

    : aws-iam-token이 mount되어 있음 - 대상, 만료기간등 포함

  - IAM token 파일 확인 : Service Account가 my-sa

  - 인증관련 공급자(IDP) 정보 확인 : issuer

 

-----------------------------------------------------------------------------------------------

이 내용은 AEWS(AWS EKS Workshop Study) 1기의 과제로써 작성되었습니다.

AEWS는 '가시다'님이 속한 CloudNet@에서 진행하는 AWS EKS workshop에 대한 스터디입니다.

매주 일요일마다 소중한 정보를 퍼주시는 '가시다'님께 무한 감사 드립니다.

https://gasidaseo.notion.site/23-AWS-EKS-Workshop-07165aec800042b9ac9357aee18fdf17