0부터 시작하는 AWS 공부 - EKS 활용하기 - EKS에 IAM USER 추가하기

Jaehong Lee·2023년 4월 10일
5
post-thumbnail

1. EKS에 IAM User 추가

EKS Cli 작업용 IAM 계정이 특정 Namespace에만 접근할 수 있도록, EKS 클러스터에 IAM 사용자를 추가하고, Role을 부여하자

참조 : https://aws-diary.tistory.com/132


RBAC & ABAC

RBAC ( 역할 기반 접근 제어 ) 는 접근 권한을 부여된 역할에 따라 결정한다

  • 액세스, 운영, 세션

ABAC ( 속성 기반 접근 제어 ) 는 접근 권한을 사용자, 리소스 속성 또는 환경에 따라 결정한다

  • 사용자, 리소스 속성, 환경
  • ABAC는 권한에 대한 내용을 파일로 관리하기 때문에 권한을 변경하려면, Master Node에 들어가서 파일을 변경하고, ApiServer를 재시작해줘야 한다

  • RBAC와 ABAC의 장단점은 위와 같다

RBAC와 ABAC는 서로 상반된 개념이 아니다. RBAC에서 발생할 수 있는 문제를 ABAC에서 해결할 수 있으며, ABAC에서 발생할 수 있느 문제를 RBAC에서 해결할 수 있다

  • 쿠버네티스에서 ABAC와 RBAC 모두 있다
  • 쿠버네티스의 RBAC은 역할을 기반으로 쿠버네티스 시스템의 권한을 관리하며, 특정 사용자 / 그룹과 역할을 묶어서 권한을 부여한다

우리는 RBAC를 통해 Group에게 역할을 부여하고, 해당 Group에 IAM User를 추가하여, IAM User가 특정 Namespace에만 접근할 수 있게 할 것이다


Namespace 생성

Namespace는 용도에 따라 컨테이너와 그에 관련된 리소스를 논리적으로 구분 짓는 그룹의 역할을 한다. 논리적으로 구분된 그룹에 대하여 권한 관리, 리소스 제한 등을 할 수 있다. Namespace는 Kubernetes 상의 Api 오브젝트를 논리적으로 구분하여 그룹핑한다

  • 예를 들면, 회사가 여러 고객들의 포드를 관리해주는 업체라면, 각 고객사별로 별도의 네임스페이스를 할당하고, 해당 네임스페이스에서 pod, svc 등을 이용한 서비스를 제공해야 한다

쿠버네티스에서 Namespace 단위에서 리소스 접근을 제어하기 위한 방식은 4가지이다

  • Node( Kubelet에서 접근 제어 ), ABAC, RBAC, Webhook( Post 요청에 대한 접근 제어 )
kubectl create namespace hongspace
  • namespace를 배포하자

Role & RoleBinding

Role : 하나의 Namespace에서 특정 Api, 리소스, 사용 권한을 명시한 규칙들의 집합이며, Role이 속한 Namespace 한 곳에만 적용된다. 해당 Role을 사용자 / 그룹이나 SA에 부여하려면 Rolebinding이 필요하다

[ec2-user@ip-192-168-11-50 hong]$ cat hongrole.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: hongrole
  namespace: hongspace # 네임스페이스 지정
rules:
  - apiGroups: ["*"] # 모든 API 접근 가능
    resources: ["*"] #  모든 리소스 접근 가능
    verbs: ["*"] # 모든 작업 가능
  • Role을 작성하자. hongspace Namespace의 모든 리소스에 대해 모든 작업이 가능하도록 설정했다
  • 위에서 모든 API는 Kubernetes의 모든 API가 아닌, Namespace 범위의 모든 API이다
kubectl apply -f hongrole.yaml
  • Role을 배포해주자

Rolebinding : 사용자 / 그룹 또는 SA와 Role을 묶어주는 역할을 한다

  • Group은 User의 집합이다. 해당 Namespace에 다른 사용자가 추가될 수 있으므로, Group으로 지정하였다
[ec2-user@ip-192-168-11-50 hong]$ cat hongrolebind.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: hongspace # 네임스페이스 지정
  name: hongrolebind
subjects:
- kind: Group # 연결할 그룹
  name: honggroup
roleRef:
  kind: Role # 연결할 역할
  name: hongrole
  apiGroup: rbac.authorization.k8s.io
  • RoleBinding을 작성하자. 위에서 생성한 Role을 Group과 연결할 것이다
kubectl apply -f hongrolebind.yaml
  • RoleBinding을 배포하자

aws-auth 수정

aws-auth는 AWS 권한 config map으로, EKS 클러스터에 IAM 유저를 추가하려면, aws-auth에 유저를 등록해야 한다

  • Role을 연결한 Group과 IAM 사용자를 연결하자
kubectl edit -n kube-system configmap/aws-auth
  • aws-auth를 수정하자
apiVersion: v1
data:
  mapUsers: |
    - userarn: IAM USER ARN 입력
      username: IAM USER 이름 입력
      groups:
        - 그룹명 입력
  • data 부분에 mapUsers를 추가하자. 해당 부분에 연결할 IAM User arn과 groups를 지정하면 된다
  • ARN은 IAM 계정에 들어가서 복사하면 된다

저장하고 나오면 적용된다


확인하기

[ec2-user@ip-192-168-11-50 ~]$ rm -rf ~/.aws
  • 기존의 AWS 접속 정보를 삭제하자
[ec2-user@ip-192-168-11-50 ~]$ aws configure
AWS Access Key ID [None]: ***********
AWS Secret Access Key [None]: ********
Default region name [None]:
Default output format [None]:
  • EKS Cli 작업용 계정의 인증 정보를 입력하자
[ec2-user@ip-192-168-11-50 ~]$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "HMJ-hong" cannot list resource "pods" in API group "" in the namespace "default"
[ec2-user@ip-192-168-11-50 ~]$ kubectl get pod -n hongspace
No resources found in hongspace namespace.
  • 기본 Namespace에 접근하면 접근 권한이 없다고 나오지만, Role에 설정한 hongspace Namespace에 접근하면 잘 접근된다

해당 IAM 사용자는 허용한 Namespace에서만 작업할 수 있다

  • 위와 같은 구조이다
  1. IAM 사용자 생성 및 EKS에 대한 정책 부여
  2. Kubernetes Namespace와 Namespace에 대한 Role 생성
  3. Group과 Role을 RoleBinding을 통해 연결
  4. aws-auth에 IAM 사용자를 등록하고, Group에 추가

2. AWS Linux User 생성

계정 분리 구성

현재 각 IAM User별 Namespace를 나누고, 해당 Namespace에만 접근 가능하게 설정했지만, 동일한 Linux 계정인 ec2-user를 사용하는 탓에 aws configure 충돌문제가 일어난다. aws configure로 설정한 aws 인증 정보는 해당 Linux 계정과 1대1 관계이기 때문이다

  • Kubeconfig도 마찬가지로 가져오게 되면 해당 유저의 .kube 디렉토리안에 생성된다. 물론 config 파일을 다른 디렉토리에 각각 배치하여, 명령할 때마다 해당 config 파일을 지정하는 방법도 있다. 하지만 이런 방법은 불편하므로 Linux User를 나누자
  • 또한, Kubeconfig만 있다고 해서 EKS 클러스터에 접근 가능한 것이 아니다. 먼저, IAM을 이용한 사용자 인증을 해야 하기에, 해당 Kubeconfig를 소유한 올바른 aws credential 정보가 있어야 접근 가능하다
구분admin재홍현희민규
Linux Userec2-userec2-hongec2-hhec2-min
Namespaceallhongspacehhspaceminspace
K8S GROUPsystem:masterhonggrouphhgroupmingroup
  • 위와 같이 Bastion Host의 Linux 계정을 분리할 것이다

User 생성 및 설정

sudo su -
  • 원할한 작업을 위해 Root 계정으로 전환하자
adduser honguser
  • 새로운 User인 honguser를 생성하자

해당 User 계정으로 SSH 접속이 되야 한다. 이를 위해선 해당 계정의 .ssh 디렉토리 안의 Authorized_keys에 Public Key를 넣어주고, 권한 설정을 해야 한다

mkdir /home/honguser/.ssh
chmod 700 /home/honguser/.ssh
  • ssh 디렉토리르 만들고, 커미션 700을 부여하자
cp /home/ec2-user/.ssh/authorized_keys /home/honguser/.ssh/
chmod 600 /home/honguser/.ssh/authorized_keys
  • ec2-user의 authorized_keys를 복사해주고, 해당 파일에 커미션 600을 부여하자
chown -R honguser:honguser /home/honguser/.ssh
  • 복사한 Public Key의 소유자를 honguser로 변경하자. R 옵션은 하위 디렉토리까지 모두 소유권을 바꿔주는 옵션이다

해당 계정으로 Password 없이 sudo 명령을 사용할 수 있게 설정하자

# sudo vi /etc/sudoers

root ALL=(ALL) ALL
honguser ALL=NOPASSWD: ALL # 추가해야 하는 부분!
  • root ALL=(ALL) ALL가 써있는 곳을 찾아서 밑에 추가하자
  • 전체 명령어에 대해 sudo 실행 시, password 없이 실행할 수 있도록 설정하자

계정 분리 확인

  • 잘 로그인 된다

  • 서로 다른 Linux 계정으로 접속하여, 각각의 IAM 계정으로 EKS에 접근했을 때, 충돌일 발생하지 않는다

3. 조회용 계정 생성

ClusterRole

EKS 클러스터에 조회만 가능한 계정을 만들어보자

  • 클러스터 전체에 대해 조회가 가능해야 하므로, Namespace에 속하는 Role이 아니라 ClusterRole을 사용해야 한다

ClusterRole은 특정 Namespace에 속하지 않고, 클러스터 전체에 대한 API, 리소스, 사용 권한을 명시한 규칙들의 집합이며, 해당 역할을 사용자 / 그룹이나 SA에 부여하려면 ClusterRoleBinding이 필요하다


Linux User 생성

sudo su -
adduser subadmin
mkdir /home/subadmin/.ssh
chmod 700 /home/subadmin/.ssh
cp /home/ec2-user/.ssh/authorized_keys /home/subadmin/.ssh
chmod 600 /home/subadmin/.ssh/authorized_keys
chown -R subadmin:subadmin /home/subadmin/.ssh
  • Bastion Host에서 subadmin User를 생성하자

  • 잘 로그인 된다

ClusterRole Bind

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: '*'
  name: view-only
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
  • ClusterRole을 정의하자. 모든 리소스 및 Api 에 대해 조회만 가능하도록 정의했다
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: view-only-bind
  namespace: default
subjects:
  - kind: Group
    name: subadmin
roleRef:
  kind: ClusterRole
  name: view-only
  apiGroup: rbac.authorization.k8s.io
  • ClusterRoleBinding을 정의하자. Group subadmin과 ClusterRole view-only를 묶는다고 정의하였다
kubectl apply -f clusterrolesub.yaml
kubectl apply -f clusterrolebindsub.yaml
  • 모두 배포해주자

IAM 정책 생성

  • EKS의 모든 리소스에 대해 조회 작업만 가능하게 정책을 생성하자
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "eks:ListNodegroups",
                "eks:DescribeFargateProfile",
                "eks:DescribeAddonConfiguration",
                "eks:ListTagsForResource",
                "eks:ListAddons",
                "eks:DescribeAddon",
                "eks:ListFargateProfiles",
                "eks:DescribeNodegroup",
                "eks:DescribeIdentityProviderConfig",
                "eks:ListUpdates",
                "eks:DescribeUpdate",
                "eks:AccessKubernetesApi",
                "eks:DescribeCluster",
                "eks:ListClusters",
                "eks:DescribeAddonVersions",
                "eks:ListIdentityProviderConfigs"
            ],
            "Resource": "*"
        }
    ]
}
  • JSON 형식으로 보면 위와 같다

정책을 생성하자


IAM 사용자 생성

  • 사용자를 생성하자

  • 조회만 가능한 정책을 부여하자

  • 마찬가지로 ACCESS KEY를 생성해주자

AWS-AUTH 설정

자 이제 IAM 사용자를 EKS 클러스터의 SUBADMIN GROUP에 추가하자

kubectl edit -n kube-system configmap/aws-auth
  • aws-auth configmap을 수정하자
- userarn: arn:aws:iam::**********:user/HMJ-EKS-SUBADMIN
      username: HMJ-EKS-SUBADMIN
      groups:
        - subadmin
  • aws-auth에 IAM 사용자의 ARN과 Group 이름을 정의하자

확인하기

  • subadmin으로 Bastion Host에 접속하자
aws eks update-kubeconfig \
--region ap-northeast-2 \
--name HMJ-EKS-CLUSTER
  • 클러스터에서 Kubeconfig를 가져오자

  • 클러스터 전체에 대한 조회는 가능하지만, 다른 작업은 불가능하다!

  • Kubernetes API 조회도 가능하다

IAM 사용자가 EKS 클러스터에 잘 추가되었다!!!


EKS 상에서 nginx ingress Controller 사용하기

EKS 상에서 EBS CSI 드라이버를 이용한 동적 프로비저닝

profile
멋진 엔지니어가 될 때까지

8개의 댓글

comment-user-thumbnail
2023년 11월 1일

Kubectl config get-contexts 에 나오는 컨텍스트 변경해서 나오는거랑 이 iam 등록 하는 거랑 어떤 차이점(?)이 있나요? Kubectl config 쓰면 안되는지~ 자세한 설명 부탁드립니다

1개의 답글
comment-user-thumbnail
2023년 11월 1일

그리고 클러스터에서 Kubeconfig를 가져올때 configmap 에 mapuser로 등록되어잇는 user정보를 가저오는건가오? 그룹이름 상관없이 클러스터 이름만 주면 mapuser에 여러 user가 있으면 다 가져오나요?

이렇게 되먼 권한만 달랏지 kubeconfig 정보 가져와서 kubectl 명령어 쓰는거랑 바로 rolebinding 한 앞선 내용에서의 kubeconfig 정보인가져오고 하는서랑 어떤 차이가 있나오?

마지막으로 mapuser를 등록한거랑 maprole을 등록한거랑 어찌 다르니요?

1개의 답글
comment-user-thumbnail
2023년 11월 3일

Clusterrole에서 이미 view-only 롤을 만들고 롤바인딩을 해줫고 또 aws-auth에 그룹명을 추가해줫는데 별도 policy정책은 또 만들어야 하나요?

그리고 aws-auth에 group이름과 clusterolebinding 에 등록한
group이름을 동일하게 하는것만으로 알아서 맵핑되는건가요?

또한 awe-auth에 userarn을 더 추가하고 kubeconfig를.가져오면 어찌되니요?

1개의 답글
comment-user-thumbnail
2023년 11월 15일

답변을 꼭 주시면 좋겠는데 답변이 안달리군요... ㅠㅠ

  1. AWS Linux User 생성전까지 리눅스유저 하나가지고 kubectl 명령어로 특정 네임스페이스 조회가 가능했습니다. 이때는 rbac과 aws-auth설정 그리고 aws configure(.aws디렉토리생성) 만으로 가능했습니
    다. 즉 아직까진 kubeconfig를 아직 생성안한거 아닙니까? 아니면 기본으로 하나 생성되어있는겁니까???

그런데 2. AWS Linux User 생성에서는 리눅스 유저 여러명이라고 kubeconfig을 하셨는데 여러명일때 하고 그전 한명일땐 안한건지 궁금하네요...한명일때 kubeconfig가 필요없다면
말그대로 리눅스 유저 한명씩 로그인해서 aws configure를 각각 하면되지 않나요???
답변좀..부탁드립니다..

1개의 답글