[NKS] IAM을 활용한 사용자별 액세스 컨트롤

사용자가 NKS(Ncloud Kubebrnetes Service)에 액세스 및 인증할 수 있는 모드는 두가지가 있습니다.

- API

- ConfigMap

 

기본적으로 NKS를 처음 콘솔에서 만들고 Kubeconfig(config)파일을 생성하기 위해선 아래 인증 절차를 거칩니다.

- ~/.ncloud/configure 파일에 AccessKey, SecretKey, APIGW URL 입력 및 저장

- ncp-iam-authenticator 파일 다운로드

- ncp-iam-authenticator 커맨드를 활용한 NKS 인증 및 kubeconfig파일 생성

이렇게 생성된 kubeconfig(config)파일과, confugre에 입력된 인증정보, ncp-iam-authenticator파일을 가지고 클러스터의 Kube-apiserver에 접근할 수가 있는건데요(위 셋중 하나라도 없으면 인증이 실패하여 kube-apiserver에 접근이 안됩니다.)

 

때문에 configure 파일에 인증정보를 저장할때, 해당 값은 당연히 클러스터의 소유주(생성한 사용자 계정)것을 넣어줘야 합니다.

 

그럼 다른사용자(Another SubAccount)는 클러스터에 어떻게 접근할 수 있을까요?

 

실습을 통해 알아보도록 하겠습니다.

 

 

 

API인증모드

---

 

첫번째는 API인증모드 방식인데요 API 인증모드는 "액세스항목" 인증 방식이라고도 합니다.

 

테스트를 진행해보기 전 클러스터를 생성해야 할 텐데요 이때 생성 및 설정화면에서 "클러스터 인증 모드"를 API로 설정해주세요

 

다음은 설정 방법 및 테스트 시나리오 입니다.

 

1. 어드민 권한 계정으로 개발자 그룹에게 부여할 Role 및 Rolebinding 생성

2. 사용자계정 생성

3. SubAccount생성

4. ~/.ncloud/configure파일에 새로 생성한 SubAccount의 인증키 저장

5. 새로 생성한 사용자계정이 ncp-iam-authenticator 커맨드 사용할 수 있도록 파일 다운로드

6. 액세스항목 설정 통해 Sub Account와 클러스터에서 생성한 Role 및 Rolebinding 매핑

7. 새 사용자의 클러스터 접근 테스트

---

1. 어드민 권한 계정으로 개발자 그룹에게 부여할 ClusterRole 및 ClusterRolebinding 생성

root@hsj-test:~# vi restricted-access.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: developer-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - namespaces
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: developer-clusterrolebinding
subjects:
- kind: Group
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-clusterrole
  apiGroup: rbac.authorization.k8s.io
~                                       
  
root@hsj-test:~# k apply -f restricted-access.yaml 
clusterrole.rbac.authorization.k8s.io/developer-clusterrole created
clusterrolebinding.rbac.authorization.k8s.io/developer-clusterrolebinding created

 

 

 

2. 사용자계정 생성

# -m 옵션은 홈 디렉토리를 생성합니다.
# -s /bin/bash 옵션은 bash를 기본 쉘로 설정합니다.
root@hsj-test:~# useradd -m -s /bin/bash rodrigo

 

 

3. Sub Account 생성

Sub Account를 콘솔에서 생성해줍니다.

콘솔 > Sub Account > 생성하기

* Sub Account를 생성할때 API Gateway접근 권한을 부여 해야 인증키를 생성할 수 있습니다.

 

 

이렇게 생성된 SubAccount의 Access Key, Secret Key를 생성해줍니다.

Access Key 탭 > 추가 버튼 클릭 

 

 

 

4. ~/.ncloud/configure파일에 새로 생성한 SubAccount의 인증키 저장

~/.ncloud와 ~/.kube파일, 그리고 ~/.ncloud/configure파일을 생성 및 사용자의 ncp-iam-authenticator 사용권한 획득

## rodrigo사용자로 전환
root@hsj-test:~# su - rodrigo
rodrigo@hsj-test:~$ mkdir .ncloud
rodrigo@hsj-test:~$ mkdir .kube
rodrigo@hsj-test:~$ cd .ncloud
rodrigo@hsj-test:~$ vi configure
[DEFAULT]
ncloud_access_key_id = ncp_iam_##############
ncloud_secret_access_key = ncp_iam_################
ncloud_api_url = https://ncloud.apigw.ntruss.com

## NKS kube-apiserver에 접근하기 위한 기존 생성한 config파일 /home/rodrigo/.kube/config에도 복붙
rodrigo@hsj-test:$ cd .ncloud
rodrigo@hsj-test:~/.kube$ vi config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tL...
    ...
    ...
    server: https://73b124da###
  name: nks_kr_hsj-mgmt_73b124da-7eaf-439a-ab2b-d3fe5e6037b9
contexts:
- context:
    cluster: nks_kr_hsj-mgmt_73b124da-7eaf-439a-ab2b-d3fe5e6037b9
    user: nks_kr_hsj-mgmt_73b124da-7eaf-439a-ab2b-d3fe5e6037b9
  name: nks_kr_hsj-mgmt_73b124da-7eaf-439a-ab2b-d3fe5e6037b9
current-context: nks_kr_hsj-mgmt_73b124da-7eaf-439a-ab2b-d3fe5e6037b9
kind: Config
preferences: {}
users:
- name: nks_kr_hsj-mgmt_73b124da-7eaf-439a-ab2b-d3fe5e6037b9
  ...
  ...

 

 

5. 새로 생성한 사용자계정이 ncp-iam-authenticator 커맨드 사용할 수 있도록 복사 및 권한 획득

## root전환
## 새 사용자의 ncp-iam-authenticator 커맨드 사용권한 획득
root@hsj-test:~# mkdir -p /home/rodrigo/bin && cp ./ncp-iam-authenticator /home/rodrigo/bin/ncp-iam-authenticator && export PATH=$PATH:/home/rodrigo/bin

## 사용자 전환
root@hsj-test:~# su - rodrigo
rodrigo@hsj-test:~$ ls
bin
rodrigo@hsj-test:~$ ncp-iam-authenticator --help

 

 

6. 액세스항목 설정 통해 Sub Account와 클러스터에서 생성한 Role 및 Rolebinding 매핑

클러스터를 클릭 > 액세스 탭 > IAM 액세스 항목 생성하기 버튼을 클릭합니다.

 

 

롤을 매핑할 사용자 클릭

 

 

사용자이름: 사용자 이름을 입력

그룹: 클러스터에서 생성한 ClutserRoleBinding의 subjects.name을 입력합니다.(저는 developer라 설정했기에 developer로 입력합니다.)

 

 

정책을 설정합니다.

저는 클러스터에서 Role을 생성 했기에 여기는 넘어가도 됩니다.

* 만약 클러스터에서 Role을 생성 했으나, 액세스 항목 생성을 통해 정책을 추가하게 되면 해당 정책으로 덮어 씌워집니다. 즉, 클러스터에서 롤을 설정하더라도 액세스항목 설정을 NKSClusterAdminPolicy로 주면 모든 권한을 보유하게 됩니다.

Type에서 확인되는 정책들은 아래 링크에서 좀 더 자세히 확인할 수 있습니다.

• 정책 : 보안주체에 적용될 클러스터 접근 정책의 목록.
  • Scope: 정책의 적용 범위 (Cluster / Namespace)
  • Namespaces(선택사항): Scope이 Namespace인 경우 정책이 적용될 Namespace 목록. '*-ns'로 패턴 지정 가능. (최대 50개)
  • Policy: 적용될 정책
    • NKSClusterAdminPolicy: 클러스터의 모든 권한 보유
    • NKSAdminPolicy : 리소스의 대부분 권한 보유
    • NKSEditPolicy: 쓰기 권한 보유
    • NKSViewPolicy: 읽기 권한 보유

- https://guide.ncloud-docs.com/docs/k8s-iam-auth-management-access-entry

 

 

다음 및 생성하기 버튼 클릭

 

 

7. 새 사용자의 클러스터 접근 테스트

지정한 권한만큼의 요청을 할 수 있는지 테스트

rodrigo@hsj-test:~/.ncloud$ kubectl get pod -A
NAMESPACE     NAME                                                READY   STATUS    RESTARTS         AGE
devops        argocd-application-controller-0                     1/1     Running   0                17h
devops        argocd-applicationset-controller-5cbccd5c7f-wg282   1/1     Running   0                17h
devops        argocd-dex-server-7c67584d85-xglzx                  1/1     Running   0                17h
devops        argocd-notifications-controller-77497b9d87-c42gv    1/1     Running   0                17h
...
...


rodrigo@hsj-test:~/.ncloud$ kubectl get nodes
NAME                  STATUS   ROLES    AGE     VERSION
hsj-nodepool-w-5eiy   Ready    <none>   7d22h   v1.28.10
hsj-nodepool-w-5eiz   Ready    <none>   7d22h   v1.28.10


rodrigo@hsj-test:~/.ncloud$ kubectl get namespace
NAME              STATUS   AGE
default           Active   7d22h
devops            Active   7d22h
kube-node-lease   Active   7d22h
kube-public       Active   7d22h
kube-system       Active   7d22h


rodrigo@hsj-test:~/.ncloud$ kubectl get deploy -A
NAMESPACE     NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
devops        argocd-applicationset-controller   1/1     1            1           7d1h
devops        argocd-dex-server                  1/1     1            1           7d1h
devops        argocd-notifications-controller    1/1     1            1           7d1h
...
...

잘 보이는 것이 확인 됩니다.

다음은, 권한을 주지 않은 리소스는 요청 및 확인이 되는지 보겠습니다.

 

rodrigo@hsj-test:~/.ncloud$ kubectl get ingress -A
Error from server (Forbidden): ingresses.networking.k8s.io is forbidden: User "rodrigo" cannot list resource "ingresses" in API group "networking.k8s.io" at the cluster scope


rodrigo@hsj-test:~/.ncloud$ kubectl get daemonsets -A
Error from server (Forbidden): daemonsets.apps is forbidden: User "rodrigo" cannot list resource "daemonsets" in API group "apps" at the cluster scope


rodrigo@hsj-test:~/.ncloud$ kubectl get statefulsets -A
Error from server (Forbidden): statefulsets.apps is forbidden: User "rodrigo" cannot list resource "statefulsets" in API group "apps" at the cluster scope

ClusterRole에 설정되지 않은 리소스는 접근이 불가한것이 확인 됩니다.

 

이렇게 API를 활용한 클러스터 인증모드에 대해 알아보았습니다.

다음은 ConfigMap 인증모드에 대해 알아보겠습니다.