Recent Comments
Link
Recent Posts
Today
Total
«   2025/03   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
관리 메뉴

Study Memory Work

[K8S/CKA 자격증] API 인증 / rbac 인증 (문제O) 본문

Infra/Kubernetes

[K8S/CKA 자격증] API 인증 / rbac 인증 (문제O)

Hera Choi 2023. 1. 13. 17:19

API 인증 종류 

  • 역할기반 인증  (rbac)
  • attribute기반 인증 (abac)

API 인증이란(rbac)? 

  • API서버에 접근하기 위해서는 인증 작업 필요
  • Role-based access control(RBAC.역할 기반 액세스 제어) 사용자의 역할에 따라 리소스에 대한 접근 권한를 가짐
  • User  인증: 클러스터 외부에서 쿠버네티스를 조작하는 사용자 인증
  • Service Account 인증: Pod가 쿠버네티스 API를 다룰 때 사용하는 계정
  • 1.인증 / 2.권한 / 3.요청범위 확인

1-1. 인증 : User 인증 

아래 명령을 실행한다고 했을 때,

$ kubectl get pods

username인증서와 함께 API server에 요청하게 된다. 
(.kube/config 파일에 user정보와 인증서가 들어있음.)

.kube/config 에 user정보와 인증서

1-2. 인증 : Service Account 인증

service account Token과 함께 API server에 요청하게 된다. 

모든 동작 중인 pod는 service account를 가지고 있다.
pod가 APIserver에 resource에 접근에 대한 요청을 했을 때, API Server는 service account가 가진 권한에 따라  인증을 한다.

# pod의 service account 보기
$ kubectl get podtest -o yaml

pod의 service account : default 계정을 가지고 있는 것을 볼 수 있다.

serviceAccount - Default 모든 pod가 기본으로 사용할 수 있는 계정

serviceAccount - Default 의 인증정보

2-1.  권한 : Role & RoleBinding 를 이용한 권한 제어

  • 특정 유저나 ServiceAccount가 접근하려는 API에 접근 권한을 설정
  • 권한이 있는 User만 접근하도록 허용
  • Role 
    - 어떤 API를 이용할 수 있는지 정의
    - kubernetes의 사용권한을 정의
    - 지정된 네임스페이스에서만 유효
  • RoleBinding
    - 사용자/그룹 또는 Service Account와 role을 연결
    - role + user 혹은 role + service account

 

2-2. 권한 : Cluster Role과 Cluster Role Binding

Role/Role Binding은 동일한 namespace 안에서만 적용되는 반면,
Cluster Role/Cluster Role Binding 은 전체 Cluster에 적용할 수 있다.

  • Cluster Role 
    • 어떤 API를 사용할 수 있는지 권한 정의. 클러스터 전체(전체 네임스페이스)에서 유효
    • ClusterRole 예제: 
# 전체 네임스페이스의 Secret에 대한 get, watch, list할 수 있는 권한

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
	name: secret-reader
rules:
- apiGroups: [""]
  resource: ["secrets"]
  verbs: ["get","watch","list"]
  • ClusterRole Binding
    • 사용자/그룹 또는 ServiceAccount와 Cluster Role 연결
    • ClusterRoleBinding 예제: 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
	name: read-secrets-global
subjects:				# 그룹에 대한 정의
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:				# ClusterRole에 대한 정의
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

 


role/rolebinding 관련 Documents

 

Using RBAC Authorization

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decis

kubernetes.io

 

[문제3] ServiceAccount, Role, RoleBinding

작업 클러스터 : k8s

  • 애플리케이션 운영중 특정 namespace의 Pod들을 모니터할수 있는 서비스가 요청되었습니다. api-access
    네임스페이스의 모든 pod를 view할 수 있도록 다음의 작업을 진행하시오.
    • api-access라는 새로운 namespace pod-viewer라는이름의ServiceAccount를만듭니다.
    • podreader-role이라는 이름의 Role podreader-rolebinding이라는 이름의 RoleBinding을 만듭니다.
    • 앞서 생성한 ServiceAccount APIresource Pod에 대하여 watch, list, get을 허용 하도록 매핑하시오.

(풀이)

1) Namespace 생성 : api-access
2) ServiceAccount 생성 : pod-viewer in api-access
3) Role 생성 : podreader-role (watch, list, get) in api-access
4) RoleBinding 생성 : podreader-rolebinding (api-access & podreader-role)

더보기
# 시작 전, 클러스터 위치 확인 / 생성할 namespace 존재여부 체크
$ kubectl config crrunt-context
$ kubectl get namespace [api-access]

# 1. namespace 생성 : api-access
$ kubectl create namespace [api-access]

# 2. 생성한 namepace 내에 Service account 생성 : pod-viewer
$ kubectl create serviceaccount [pod-viewer] -n [api-access]
	# 생성 여부 체크
$ kubectl get serviceaccounts --namespace [api-access]

# 3. Role 생성 : podreader-role : watch, list, get 권한
$ kubectl create role [podreader-role] --verb=[watch] --verb=[list] --verb=[get] --resource=pods --namespace [api-access]
	# 생성 여부 체크
$ kubectl get role --namespace [api-access]
	# role 상세내역 체크
$ kubectl describe role --namespace api-access podreader-role

# 4. RoleBinding 생성 : podreader-rolebinding : pod-viewer & podreader-role
$ kubectl create rolebinding [podreader-rolebinding] --role=[podreader-role] --serviceaccount=[api-access]:pod-viewer -n [api-access]
	# 생성 여부 체크
$ kubectl get rolebinding --namespace [api-access]
$ kubectl describe -n [api-access] rolebindings [podreader-rolebinding]

 

[문제4] ServiceAccount, ClusterRole, ClusterRoleBinding

작업 클러스터 : k8s

  • 작업 Context에서 애플리케이션 배포를 위해 새로운 ClusterRole을 생성하고 특정 namespace의 ServiceAccount를 바인드하시오.
    • 다음의 resource type에서만 Create가 허용된 ClusterRole deployment-clusterrole을 생성합니다.
      Resource Type: 
      Deployment StatefulSet DaemonSet
    • 미리 생성된 namespace api-access  cicd-token이라는 새로운 ServiceAccount를 만듭니다.
    • ClusterRole deployment-clusterrole namespace api-access 로 제한된 새 ServiceAccount cicd-token에 바인딩합니다.

(풀이)

1) ClusterRole 생성 : deployment-clusterrole (Create. Resource Type: Deployment StatefulSet DaemonSet)
2) ServiceAccount 생성 : cicd-token in api-access
3) ClusterRole Binding 생성 : deployment-clusterrole & cicd-token in api-access.
    -> ClusterRole Binding 이름이 주어지지 않으면 직접 작명하면 된다.

# 1. cluster role 생성
$ kubectl create clusterrole deployment-clusterrole --verb=create --resource=Deployment, StatefulSet, DaemonSet

# 2. Service Account 생성
$ kubectl create serviceaccount cicd-token -n api-access

# 3. ClusterRole Binding 생성
$ kubectl create clusterrolebinding deployment-clusterrole-binding --clusterrole=deployment-clusterrole --user=api-access:cicd-token

 

[문제5(실제문제유형)] User, ClusterRole, ClusterRoleBinding

작업 클러스터 : k8s

  • CSR(Certificate Signing Request)를 통해 app-manager 인증서를 발급받은 user app-manager 에게 cluster내 모든 namespace의 deployment, pod, service 리소스를 create, list, get, update, delete 할 수 있는 권한을 할당하시오.
    • user name : app-manager
    • certificate name: app-manager
    • clusterRole name : app-access
    • clusterRoleBinding name: app-access-binding

(풀이)

1) User 생성 : app-manager
   - certificate : app-manager
2) clusterRole 생성 :  ('...cluster내 모든 namespace의....' 권한을 생성하는것은 clusterRole!) 
   - name : app-access
   - resource : deployment, pod, service
   - role : create, list, get, update, delete
3) clusterRolebindig 생성 : app-access-binding (app-manager & app-access)

# 1. certificate 생성
	# certificate 명으로 key 생성
$ openssl genrsa -out app-manager.key 2048	
	# 인증서 생성(.csr파일 : 인증서요청파일)
$ openssl req -new -key app-manager.key -out app-manager.csr -subj "/CN=app-manager"
	# 인증서 생성여부 확인 -> 현재 디렉토리에 생성됨.
    # 인증서에서 token 꺼내기
$ cat app-manager.csr | base64 | tr -d "\n"
	# 인증서 yml 파일 만들기
$ vi certificate.yml

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: app-manager
spec:
  request: {{위에서 꺼낸 token}}
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
  
	# csr 생성
$ kubectl apply -f certificate.yml
	# csr 생성여부 확인 (pending 상태)
$ kubectl get csr
	# csr 승인요청
$ kubectl certificate approve app-manager
	# csr 생성여부 확인 (생성 완료)
$ kubectl get csr



# 2. User 인증서 생성 (현재 디렉토리에 생성됨. .crt파일)
$ kubectl get csr app-manager -o jsonpath='{.status.certificate}'| base64 -d > app-manager.crt



# 3. Cluster Role 생성
$ kubectl create clusterrole app-access --verb=create,list,get,update,delete --resource=deployment,pod,service



# 4. Cluster Role Binding 생성
$ kubectl create clusterrolebinding app-access-binding —clusterrole=app-access --user=app-access