[AEKS2] 6주차 - EKS Security: EKS API 인증 모드

EKS에서는 인증(Authentication) 방식을 좀더 쿠버네티스 네이티브하게 변경해서 편리하게 사용하기 위해 EKS API 방식을 도입했다. (ConfigMap 수정 시 크리티컬한 요소도 있기 때문)

현재는 EKS API 및 ConfigMap 방식으로 동시에 사용하고 있지만 점차 EKS API 방식으로 전환될 것이다. 또한 한번 EKS API 방식으로 인증 모드를 변경하게 되면 다시 원복이 불가능하다.

인증 모드는 aws cli 혹은 EKS 콘솔에서 변경할 수 있다.

aws eks update-cluster-config --name $CLUSTER_NAME --access-config authenticationMode=API

Access Policy

EKS API 모드에 Aceess Policy는 네 가지가 있다

클러스터 관리자 권한, 일반 관리자 권한, 편집 권한, 읽기 권한이 있다.

• AmazonEKSAdminPolicy

• AmazonEKSClusterAdminPolicy

  ⇒ 클러스터를 생성한 User에게 자동으로 부여되는 권한이다.

  

• AmazonEKSEditPolicy
• AmazonEKSViewPolicy

Associating and disassociating access policies to and from access entries - Amazon EKS

각각의 Policy는 아래 K8S User와 매핑되어 있다.

EKS API 모드 실습

EKS API 모드에서는 Configmap 수정없이 api 요청을 보낸다고 생각하면 된다.

access entry를 생성해서 정책을 연결해서 사용하면 된다.

실습하려는 사용자인 testuser는 이미 IAM Policy로 Administrator Access 권한을 가지고 있다.

(1) 기본 관리형 정책 사용

기본 정책 네 가지 중에 한 가지를 선택해서 사용할 수 있다.

1. testuser의 access entry를 생성하고

    aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser
   

   

2. 관리형 Access Policy 중에 AmazonEKSClusterAdminPolicy를 연결한다.

    aws eks associate-access-policy --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser \
      --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster
   

   이는 aws cli 혹은 콘솔에서 확인할 수 있다.

   aws eks list-associated-access-policies --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq

   

   

3. kubectl 실행이 가능하지만 aws-auth에는 반영되지 않아 있다. 이것이 바로 API 인증 모드이다.

   

(2) Custom 정책 사용

관리형 정책이 아닌 Custom으로 생성한 정책을 Role&RoleBinding 연결해서 사용자에게 권한을 부여해 줄 수도 있다.

일단 aws cli로

aws eks delete-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser 로 위에 생성한 정책을 지우고 시작한다.

1. 클러스터 전체 권한을 부여하기 위해 ClusterRole을 생성한다.

    cat <<EoF> ~/pod-viewer-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pod-viewer-role
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["list", "get", "watch"]
    EoF
       
    kubectl apply -f ~/pod-viewer-role.yaml
   

2. group과 ClusterRole을 매핑하기 위해 ClusterRoleBinding을 생성한다.

    kubectl create clusterrolebinding viewer-role-binding --clusterrole=pod-viewer-role --group=pod-viewer
   

3. 위에 ClusterRole과 ClusterRoleBinding은 권한 정책을 생성한 것이고 access-entry 생성하여 user-group-권한을 연결해 준다.

    aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-viewer
   

4. aws cli 혹은 콘솔에서 생성된 user-정책을 확인한다.

   aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq

   

   

5. 그리고 실제 testuser의 터미널에 들어가서 권한을 확인해 보면,

   get 권한은 yes로, delete 권한은 no로 표시됨을 확인할 수 있다.

   

EKS API 인증으로 실행해 보면서 Configmap의 휴먼 에러에 대해 좀 안심할 수 있을 것 같다. 그리고 EKS 콘솔에 접근 권한 설정이 가시적으로 보이면서 관리자가 액세스에 대한 파악이 더 쉬울 것 같다는 생각이 들었다.