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

사용자가 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)는 클러스터에 어떻게 접근할 수 있을까요?

 

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

 

 

ConfigMap

---

이전 장에서는 API모드를 활용한 인증 방법에 대해 작성해봤는데요

이번에 ConfigMap을 활용한 인증 방법에 대해 알아보겠습니다.

 

먼저, 클러스터를 생성할 때 "클러스터 인증 모드"를 ConfigMap으로 설정해주세요

 

 

다음은 테스트 시나리오입니다.

이전 글에서 이미 따라해보신 분은 5번까지 생략하셔도 됩니다.
같은 사용자 및 Sub Account로 테스트 합니다.

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. ConfigMap을 통해 Sub Account와 클러스터에서 생성한 Role 및 Rolebinding 매핑

root@hsj-test:~# vi ncp-auth.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: ncp-auth
  namespace: kube-system
data:
  mapSubAccounts: |
    - subAccountIdNo: 3942c###
      username: rodrigo
      groups:
        - developer
        
# ConfigMap의 IAM 사용자 파라미터는 아래와 같습니다.
# 	 subaccountIdNo: SubAccount 콘솔에서 확인 가능한 추가할 SubAccount 사용자의 ID
# 	 username: Kubernetes 내에서 IAM 사용자에게 매핑할 사용자 이름.
# 	 groups: Kubernetes 내에서 사용자에게 매핑할 그룹 목록. ClusterRoleBinding에서 설정한 Group명

root@hsj-test:~# k apply -f ncp-auth.yaml 
configmap/ncp-auth created

 

data.mapSubAccounts.subAccountIdNo의 경우 해당 서브어카운트의 정보를 통해 확인할 수 있습니다

 

 

 

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

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


rodrigo@hsj-test:~$ kubectl get po -A
NAMESPACE     NAME                                                READY   STATUS    RESTARTS         AGE
devops        argocd-application-controller-0                     1/1     Running   0                20h
devops        argocd-applicationset-controller-5cbccd5c7f-wg282   1/1     Running   0                21h


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


rodrigo@hsj-test:~$ kubectl get daemonsets
Error from server (Forbidden): daemonsets.apps is forbidden: User "rodrigo" cannot list resource "daemonsets" in API group "apps" in the namespace "default"

권한을 부여한 리소스의 경우 get이 정상적으로 되는데, 권한에서 제외한 리소스의 경우 get이 안되는 것을 확인할 수 있습니다.

 

지금까지 ConfigMap을 활용한 사용자 액세스 컨트롤 방법이었습니다.

 

액세스항목 설정 방식과, ConfigMap방식의 차이는 결국 콘솔에서 사용자 액세스를 관리하느냐, 클러스터 내 ConfigMap을 통해 관리하느냐의 차이인 것 같습니다.

 

다만 액세스항목 설정 방식의 경우 Role을 콘솔에서 설정하게 된다면 클러스터에서는 Role을 생성할 필요가 없다는 장점이 있겠지만, 현재 NKS에서는 사용자별로 세부적인 정책 설정을 하지 못하고, 다소 광범위하게 설정할 수 있어 이는 단점으로 작용할 수 있을 것 같습니다.