참고
KubeConfig
NOTE
kubeconfig는 cluster, user, context에 대한 정보를 담는 config파일이다!
K8s에서 client는 인증서를 사용하기 위해 curl명령어를 이용하여 쿼리를 한다.
•
이런 명령어가 너무 길어지면 실수를 하고, 매번 이렇게 치는것은 힘든일이다.
그래서 KubeConfig File개념이 등장했다.
•
여기에 작성을 해 두고, 조회나 curl시 kubeConfig를 이용하여 인증서를 조회할 수 있다.
•
그리고 kubeConfig는 Cluster, Contexts, Users로 구분된다.
•
kubeConfig file은 $HOME/.kube/config 디렉토리에 존재한다.
Cluster + User ⇒ Contexts
apiVersion: v1
kind: Config
clusters:
- name: Deployment
cluster:
certificate-authority: ca.crt
server: https://172.17.0.51:6443
contexts:
- name: admin@production
context:
cluster: Deployment
user: admin
namespace: finance
users:
- name: admin
user:
client-certificate: admin.crt
client-key: admin.key
YAML
복사
cluster와 users의 내용을 합쳐서 contexts 생성
kubectl config 명령어
NOTE
k config current-context # 현재 컨텍스트
k config get-contexts # 컨텍스트 목록보기
k config use-context [context-name] # 변경할 컨텍스트
kubectl config set-context [컨텍스트 이름]
--cluster=[클러스터 이름[
--user=[유저 이름]
--namespace=[네임스페이스 이름]
echo $KUBECONFIG # kubeconfig 파일 경로 확인
Bash
복사
Authorization
NOTE
Authorization(인가)는 클러스터가 다양한 Clients들과 함께 사용되는데, 권한에따라 기능을 제한하기 위해 생겨난 개념이다!
일반 개발자가 기밀정보를 볼 수 없어야 한다.
권한에 대한 매커니즘은 크게 4가지가 있다.
•
Node Authorization: 스케줄링 된 파드의 kubelet 접근제어
•
ABAC: 속성기반 접근제어
•
RABC: 역할기반 접근제어
•
Webhook: POST 요청에 대한 접근제어
Service Account
NOTE
권한을 부여하기 위한 계정을 만들어보자!
1.24부터 계정생성시 토큰값이 자동으로 생성되지 않음
kubectl create serviceaacount [계정 이름]
kubectl get serviceaccount # 각 네임스페이스마다 default로 기본 생성
kubectl describe serviceaccount [계정 이름] # 토큰이 secret로 생성됨(최신버전에선 X)
kubectl describe secret [토큰 이름]
kubectl exec -it [pod 이름] -- ls /var/run/secrets/kubernetes.io/serviceaccount
kubectl exec -it [pod 이름] -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
Bash
복사
API버전(그룹) 확인
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-service-account # 이 부분을 설정
containers:
- name: my-container
image: nginx:1.18
YAML
복사
pod에 계정설정
모든 Pod들은 기본값으로 default ServiceAccount를 가지고 있다. 수정하기 위해서는 spec.serviceAccountName 값에 계정이름을 설정하면 된다.
RABC(Role, ClusterRole)
NOTE
RABC는 역할기반 접근제어 방식이며 역할(Role) + 역할 매핑(RoleBinding)로 구성된다!
Role vs ClusterRole
clusterscope는 클러스터 전체에 걸쳐 존재해 모든 네임스페이스에서 동일하게 확인이 가능하다.
•
Role은 특정 네임스페이스 내에서 리소스에 대한 접근 권한을 정의하기 위해 사용한다.
•
Cluster Role은 모든 네임스페이스와 관련된 리소스에 대한 접근 권한을 정의할 수 있다.
# Role을 정의하는 리소스입니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
rules:
# 이 Role은 Pod 리소스에 대한 'list', 'get', 'create', 'update' 권한을 부여합니다.
- apiGroups: [""]
resources: ["pods"]
verbs: ["list", "get", "create", "update"]
# 이 Role은 ConfigMap 리소스에 대한 'create' 권한을 부여합니다.
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
YAML
복사
ex-role.yaml
# RoleBinding을 정의하는 리소스입니다. 이는 특정 Role을 특정 사용자나 그룹에 연결(bind)하는 역할을 합니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: devuser-developer-binding
subjects:
# 'dev-user'라는 이름의 사용자를 대상으로 합니다.
- kind: User
name: dev-user
apiGroup: rbac.authorization.k8s.io
roleRef:
# 위에서 정의한 'developer' Role을 참조합니다.
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.io
YAML
복사
role-bindin.yaml
# ClusterRole 리소스를 정의하는 섹션입니다.
apiVersion: rbac.authorization.k8s.io/v1 # Kubernetes RBAC API 버전을 사용합니다.
kind: ClusterRole
metadata:
name: cluster-administrator
- apiGroups: [""]
resources: ["nodes"]
verbs: ["list", "get", "create", "delete"]
YAML
복사
cluster-role.yaml
# ClusterRoleBinding 리소스를 정의하는 섹션입니다.
apiVersion: rbac.authorization.k8s.io/v1 # Kubernetes RBAC API 버전을 사용합니다.
kind: ClusterRoleBinding # 이 리소스의 유형은 ClusterRoleBinding입니다.
metadata:
name: cluster-admin-role-binding
subjects:
- kind: User # User를 대상으로 하는 권한 연결입니다.
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole # 연결할 권한의 유형을 지정합니다. 여기서는 ClusterRole입니다.
name: cluster-administrator
apiGroup: rbac.authorization.k8s.io
YAML
복사
cluster-binding.yaml
RABC의 조합
1.
Role + RoleBinding
•
특정 네임스페이스의 리소스를 단일 네임스페이스에 적용
•
ex) 하나의 네임스페이스 내에서만 리소스에 대한 권한부여
2.
ClusterRole + ClusterRoleBinding
•
클러스터 레벨 권한을 클러스터 전체에 부여한다.
•
ex) 모든 네임스페이스에서 파드 생성,조회 가능
3.
ClusterRole + RoleBinding
•
클러스터 레벨 권한을 단일 네임스페이스 내의 사용자, 서비스 어카운트에 적용
API 그룹
NOTE
API 그룹은 쿠버네티스 API 리소스를 관리하기 위해 그룹화한 것이다!
API Group 모습
kubectl api-resources
Bash
복사
API버전(그룹) 확인