Passwd

kube-apiserver에 요청이 도착하면, 요청을 수행하고 그 정보를 ETCD database에 저장된다. 요청을 수행하기 전에는 인증 과정(Authentication)이 필요하다. kubectl을 통해 요청이 전송되었다면 인증서가 구성된 kubeconfig 파일의 정보를 이용해 사용자를 식별하고, 유효한 사용자인지 확인한다. 인증 과정 후에는 사용자가 요청한 작업을 수행할 수 있는 권한이 있는지 확인하는 권한 부여 과정(Authorizaition)을 거치며, 이 과정에는 보통 역할 기반 접근 제어(RBAC)를 사용한다. RBAC 여러 개체의 제어를 허용하거나 거부하는 역할을 사용자에게 부여하여 접근을 제한하는 방법이다. 특정 리소스(resourceName)만을 허용하거나 특정 네임스페이스의 접근만을..

Namespace Scope Resource Role과 RoleBinding 객체는 namespace 내에 생성되어 해당 namespace 내 자원에 대한 접근만을 제어한다. 생성 시 namespace를 지정하지 않으면 default namespace에 생성된다. namespace 내에 생성되는 자원은 Role, RoleBinding 외에도 Pod, ReplicaSet, Deployment, Job, Service, Secret 등이 존재하여, 그 외 해당되는 자원은 아래 명령어로 확인할 수 있다. Namespace Scope Resource 확인 kubectl api-resources --namespaced=true Cluster Scope Resource 특정 namespace에 한정되지 않는 clu..

Role Based Access Control을 사용하기 위해서는 권한 집합을 정의한 role과 user의 role을 정의하는 roleBinding을 생성해야 한다. Role Role을 정의하는 yaml 형식의 파일은 아래와 같으며, create 명령으로 생성할 수 있다. 하나의 Role은 여러 규칙을 가질 수 있으며, 하나의 규칙은 접근을 허용할 apiGroup과 resources, 그리고 자원에 허용할 작업을 나타내는 verbs으로 이루어져 있다. apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer rules: - apiGroups: [""] resources: ["pods"] # 권한을 부여할 자원 verbs: ..

Authorization 사용자가 클러스터에 접근하여 할 수 있는 것을 정의한다. 예시 ) 관리자 : Pod, Node, Deployment와 같은 객체 확인/생성/삭제 개발자 : 클러스터 구성 수정 제한, 애플리케이션 Deployment 접근 허용 Service Account : 외부 애플리케이션 접근 허용 여러 조직 또는 팀과 클러스터 공유 시, 클러스터를 네임스페이스로 분리하여 접근 통제 권한 부여 메커니즘 Node authorization kubelet은 apiserver에 접근하여 service, endpoint, node, pod의 정보를 읽거나 node 상태와 같은 정보를 apiserver에 전달한다. 이러한 요청은 node authorizer에 의해 처리되며, 사용자 이름이 system:n..

사용자는 kubectl을 이용하거나 kube-apiserver와 직접 상호작용하여 Kubernetes API를 사용할 수 있다. 예시 - kubenetes 클러스터 버전 확인 curl /version # 예시 curl https://kube-master:6443/version - 포드 목록 확인 curl /version # 예시 curl https://kube-master:6443/version API Group api resource를 묶어놓은 그룹으로. yaml 파일 작성 시 apiVersion에 명시된다. Kubernetes API는 상태 모니터링, 메트릭 수집, 로그 등의 목적에 따라 그룹화된다. 목적 api 경로 Group 비고 클러스터 상태 모니터링 /metrics /healthz 클러스터의 ..

KubeConfig kubectl을 사용할 때 인증 정보를 지정하지 않고 사용할 수 있도록 인증 정보를 저장한 설정 파일 즉, kubectl 사용 시 사용할 인증 정보를 저장한 파일 Kubernetes 사용자는 생성해둔 인증서 파일과 키를 지정하여 curl을 이용해 kube-apiserver에 쿼리를 요청할 수 있다. curl - 포드 목록 확인 curl https://my-kube-playground:6443/api/v1/pods \ --key admin.key \ --cert admin.crt \ --cacert ca.crt kubectl을 사용할 때도 마찬가지로, 인증 정보를 지정하여 kube-apiserver에 요청을 전달할 수 있다. kubectl - 포드 목록 확인 kubectl get pod..

Kubernetes 클러스터는 물리 노드, 가상 노드 및 동작하는 다양한 요소로 구성되어 있다. Kubernetes 클러스터는 인증 및 권한 부여 메커니즘을 이용해 구성 요소 간 통신과 클러스터에 대한 접근 관리성을 확보함으로써 보호되어야 한다. 사용자 쿠버네티스는 기본적으로 사용자 계정을 관리하지 않는다. 즉, kubectl create user와 같은 명령어로 사용자를 생성할 수 없고, kubectl get users와 같은 명령어로 사용자를 확인할 수도 없다. 쿠버네티스는 인증서, LDAP과 같은 서비스, 사용자 정보가 저장된 정적 파일 등을 이용해 사용자를 관리한다. 단, Service Accounts는 쿠버네티스에 생성하고 관리할 수 있다. 사용자 유형 인간 User Accounts 관리자 : ..

쿠버네티스 클러스터에서 보안이 필요한 부분과 그 방법에 대해 정리한다. 호스트 쿠버네티스 클러스터를 형성한 호스트에 대한 접근은 보호되어 있어야 한다. 비밀번호 인증 접근은 제한되어야 하며, SSH 키 인증 접근만이 허용되어야 한다. kube-apiserver kube-apiserver는 쿠버네티스 내 모든 작업의 중심으로, 사용자는 kubectl를 이용하거나 apiserver에 직접 접근하여 클러스터와 상호작용할 수 있다. 클러스터에서 거의 모든 작업을 kube-apiserver를 통해 수행할 수 있으므로 apiserver 자체에 대하 접근 제어가 필수적이다. 고려사항 누가 클러스터에 접근할 수 있는가 ID/PASSWD, Token, 인증서, 외부 인증 공급자(LDAP), Service Accounts..

PV와 PVC를 이용하면 퍼시스턴트 스토리지를 쉽게 사용할 수 있지만 클러스터 관리자가 실제 스토리지를 프로비저닝해두어야 한다는 불편함이 있다. 쿠버네티스는 이 작업을 자동으로 수행할 수 있도록 PV 동적 프로비저닝(Dynamic Provisioning)을 지원하여, PV 프로비저너를 배포하고 사용자가 선택 가능한 PV 타입을 정의하는 스토리지 클래스(SC, Storage Class) 객체를 기반으로 지원한다. 이 글에서는 Storage Class 목록을 확인하고, 생성하는 명령어를 정리해둔다. Storage Class 목록 확인 get 명령을 이용해 Storage Class의 목록을 확인할 수 있다. kubectl get storageclasses.storage.k8s.io Storage Class 상..

Pod는 수시로 삭제되었다가 재생성되는데, 삭제 시에 포드 내부에 있는 데이터도 함께 삭제된다. 유지해야 하는 데이터가 존재한다면 Volume을 구성해 Pod에 마운트해야 한다. 이 글에서는 Volume 구성 및 PV/PVC를 이용한 구성 및 확인 명령어에 대해 정리한다. Volume (HostPath) 구성 포드 생성 yaml 파일에 .spec.containes.volumeMounts 필드와 .spec.volumes 필드를 작성하여 구성한다. apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: webapp name: webapp spec: containers: - image: kodekloud/event-simulator na..