Passwd

Validating Admission Controller 요청을 검증하는 검증 승인 컨트롤러 예시 ) NamespaceExist NamespaceLifecycle 요청 내용의 네임스페이스가 존재하는지 확인하고 없으면 요청을 거부한다. Mutating Admission Controller 요청 수행 전에 요청 내용을 변경할 수 있다. 예시 ) DefaultStorageClass : 기본 활성화 플러그인으로, PVC 생성 요청을 확인하여 PVC에 StorageClass 설정이 존재하는지 확인한다. StorageClass 설정이 없는 경우, default StorageClass로 구성하도록 StorageClasss 설정을 수정한다. Admission Controller는 요청을 검증하는 Validating a..

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로 포드 내에서 볼륨을 사용할 수 있다. 또는 스토리지 클래스를 정의하여 provisioner를 이용해 볼륨을 자동으로 프로비저닝할 수 있다. Stateful Set yaml 형식의 정의 파일에서 같은 PVC를 설정하면, Stateful Set에서 생성한 모든 포드가 같은 볼륨을 사용한다. 여러 포드 또는 애플리케이션의 여러 인스턴스가 같은 스토리지를 공유하고 접근하는 경우에 해당한다. 하지만 각 포드에 별도의 볼륨이 필요한 경우, 즉 데이터 공유를 하지 않는 경우에는 각 포드에 로컬 스토리지가 필요하다. volumeClaimTemplete 배열이기 때문에 여러 템플릿을 지정할 수 있다. apiVersion: apps/v1 kind: StatefulSet..