- 액세스, 운영, 세션
- 사용자, 리소스 속성, 환경
- ABAC는 권한에 대한 내용을 파일로 관리하기 때문에 권한을 변경하려면, Master Node에 들어가서 파일을 변경하고, ApiServer를 재시작해줘야 한다
- RBAC와 ABAC의 장단점은 위와 같다
- 쿠버네티스에서 ABAC와 RBAC 모두 있다
- 쿠버네티스의 RBAC은 역할을 기반으로 쿠버네티스 시스템의 권한을 관리하며, 특정 사용자 / 그룹과 역할을 묶어서 권한을 부여한다
- 예를 들면, 회사가 여러 고객들의 포드를 관리해주는 업체라면, 각 고객사별로 별도의 네임스페이스를 할당하고, 해당 네임스페이스에서 pod, svc 등을 이용한 서비스를 제공해야 한다
- Node( Kubelet에서 접근 제어 ), ABAC, RBAC, Webhook( Post 요청에 대한 접근 제어 )
kubectl create namespace hongspace
- namespace를 배포하자
[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을 배포해주자
- 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을 배포하자
- 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 사용자 생성 및 EKS에 대한 정책 부여
- Kubernetes Namespace와 Namespace에 대한 Role 생성
- Group과 Role을 RoleBinding을 통해 연결
- aws-auth에 IAM 사용자를 등록하고, Group에 추가
- Kubeconfig도 마찬가지로 가져오게 되면 해당 유저의 .kube 디렉토리안에 생성된다. 물론 config 파일을 다른 디렉토리에 각각 배치하여, 명령할 때마다 해당 config 파일을 지정하는 방법도 있다. 하지만 이런 방법은 불편하므로 Linux User를 나누자
- 또한, Kubeconfig만 있다고 해서 EKS 클러스터에 접근 가능한 것이 아니다. 먼저, IAM을 이용한 사용자 인증을 해야 하기에, 해당 Kubeconfig를 소유한 올바른 aws credential 정보가 있어야 접근 가능하다
구분 | admin | 재홍 | 현희 | 민규 |
---|---|---|---|---|
Linux User | ec2-user | ec2-hong | ec2-hh | ec2-min |
Namespace | all | hongspace | hhspace | minspace |
K8S GROUP | system:master | honggroup | hhgroup | mingroup |
- 위와 같이 Bastion Host의 Linux 계정을 분리할 것이다
sudo su -
- 원할한 작업을 위해 Root 계정으로 전환하자
adduser honguser
- 새로운 User인 honguser를 생성하자
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 옵션은 하위 디렉토리까지 모두 소유권을 바꿔주는 옵션이다
# sudo vi /etc/sudoers
root ALL=(ALL) ALL
honguser ALL=NOPASSWD: ALL # 추가해야 하는 부분!
- root ALL=(ALL) ALL가 써있는 곳을 찾아서 밑에 추가하자
- 전체 명령어에 대해 sudo 실행 시, password 없이 실행할 수 있도록 설정하자
- 잘 로그인 된다
- 서로 다른 Linux 계정으로 접속하여, 각각의 IAM 계정으로 EKS에 접근했을 때, 충돌일 발생하지 않는다
- 클러스터 전체에 대해 조회가 가능해야 하므로, Namespace에 속하는 Role이 아니라 ClusterRole을 사용해야 한다
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를 생성하자
- 잘 로그인 된다
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
- 모두 배포해주자
- 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 형식으로 보면 위와 같다
- 사용자를 생성하자
- 조회만 가능한 정책을 부여하자
- 마찬가지로 ACCESS KEY를 생성해주자
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 조회도 가능하다
EKS 상에서 nginx ingress Controller 사용하기
EKS 상에서 EBS CSI 드라이버를 이용한 동적 프로비저닝
그리고 클러스터에서 Kubeconfig를 가져올때 configmap 에 mapuser로 등록되어잇는 user정보를 가저오는건가오? 그룹이름 상관없이 클러스터 이름만 주면 mapuser에 여러 user가 있으면 다 가져오나요?
이렇게 되먼 권한만 달랏지 kubeconfig 정보 가져와서 kubectl 명령어 쓰는거랑 바로 rolebinding 한 앞선 내용에서의 kubeconfig 정보인가져오고 하는서랑 어떤 차이가 있나오?
마지막으로 mapuser를 등록한거랑 maprole을 등록한거랑 어찌 다르니요?
Clusterrole에서 이미 view-only 롤을 만들고 롤바인딩을 해줫고 또 aws-auth에 그룹명을 추가해줫는데 별도 policy정책은 또 만들어야 하나요?
그리고 aws-auth에 group이름과 clusterolebinding 에 등록한
group이름을 동일하게 하는것만으로 알아서 맵핑되는건가요?
또한 awe-auth에 userarn을 더 추가하고 kubeconfig를.가져오면 어찌되니요?
답변을 꼭 주시면 좋겠는데 답변이 안달리군요... ㅠㅠ
그런데 2. AWS Linux User 생성에서는 리눅스 유저 여러명이라고 kubeconfig을 하셨는데 여러명일때 하고 그전 한명일땐 안한건지 궁금하네요...한명일때 kubeconfig가 필요없다면
말그대로 리눅스 유저 한명씩 로그인해서 aws configure를 각각 하면되지 않나요???
답변좀..부탁드립니다..
Kubectl config get-contexts 에 나오는 컨텍스트 변경해서 나오는거랑 이 iam 등록 하는 거랑 어떤 차이점(?)이 있나요? Kubectl config 쓰면 안되는지~ 자세한 설명 부탁드립니다