쿠버네티스에서는 Authenticate/Authorization/Admission Control 이라는 세 단계를 통해서 리소스가 등록된다.
Authenticate
Authentication 에서는 사용자명과 패스워드, 사용자명과 토큰으로 정상 사용자인지 확인한다. 그 외에 Certificates, External Authentication providers(LDAP 등), Service Accounts 을 사용하는 것도 가능하다.
kube-apiserver Basic authenticate 예시
- Auth file
# Static Password File
# user-details.csv
password123,user1,u0001
password123,user2,u0002
password123,user3,u0003
password123,user4,u0004
password123,user5,u0005
- curl -v -k https://master-node-ip:6443/api/v1/pods -u "user1:password123"
# Static Token File
# user-token-details.csv
# --token-auth-file=user-details.csv
KpjCVbI7rCFAHYPkByTIzRb7gu1cUc4B,user10,u0010,group1
rJjncHmvtXHc6MlWQddhtvNyyhgTdxSC,user11,u0011,group1
mjpOFIEiFOkL9toikaRNtt59ePtczZSq,user12,u0012,group2
PG41IXhs7QjqwWkmBkvgGT9glOyUqZij,user13,u0013,group2
- curl -v -k https://master-node-ip:6443/api/v1/pods --header "Authorization: Bearer KpjCVbI7rCFAHYPkBzRb7gu1cUc4B"/etc/kubernetes/manifests/kube-apiserver.yaml : basic-auth-file
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
- --authorization-mode=Node,RBAC
- --advertise-address=172.17.0.107
- --allow-privileged=true
- --enable-admission-plugins=NodeRestriction
- --enable-bootstrap-token-auth=true
- --basic-auth-file=user-details.csv
image: k8s.gcr.io/kube-apiserver-amd64:v1.11.3
name: kube-apiserver
Kubeadm basic authentication 예시
/tmp/users/user-details.csv
# User File Contents
password123,user1,u0001
password123,user2,u0002
password123,user3,u0003
password123,user4,u0004
password123,user5,u0005
Edit the kube-apiserver static pod configured by kubeadm to pass in the user details.
The file is located at /etc/kubernetes/manifests/kube-apiserver.yaml
Change Volume Mounts : /tmp/users
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
<content-hidden>
image: k8s.gcr.io/kube-apiserver-amd64:v1.11.3
name: kube-apiserver
volumeMounts:
- mountPath: /tmp/users
name: usr-details
readOnly: true
volumes:
- hostPath:
path: /tmp/users
type: DirectoryOrCreate
name: usr-details
Modify the kube-apiserver startup options to include the basic-auth file
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
- --authorization-mode=Node,RBAC
<content-hidden>
- --basic-auth-file=/tmp/users/user-details.csv
Create the necessary roles and role bindings for these users : user1
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
# This role binding allows "user1" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: user1 # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
Once created, you may authenticate into the kube-api server using the users credentials
curl -v -k https://localhost:6443/api/v1/pods -u "user1:password123"
Authorization
Authorization 에서는 그 사용자가 하고자 하는 요청에 대해 실행 가능한 권한이 있는지를 제어한다.
RBAC(Role Based Access Control)는 어떤 조작을 허용하는지를 결정하는 롤을 생성하고 서비스 어카운트 등의 사용자에게 롤을 연결하여(롤바인딩) 권한을 부여한다. 또 AggregationRule을 사용하여 여러 롤을 집약한 롤을 생성할 수 있어 롤 관리성을 향상시킬 수 있다.
롤과 롤바인딩에는 네임스페이스 수준의 리소스(롤과 롤바인딩)와 클러스터 수준의 리소스(클러스터롤과 클러스터롤바인딩)가 있다.
kube-apiserver에서 RBAC 설정
kube-apiserver authorization-mode : AlwaysAllow or Node, RBAC, Webhook ...
ExecStart=/usr/local/bin/kube-apiserver \\
--advertise-address=${INTERNAL_IP} \\
--allow-privileged=true \\
--apiserver-count=3 \\
--authorization-mode=AlwaysAllow, RBAC, Webhook \\
--bind-address=0.0.0.0 \\
Role 정의
- kubectl get roles
- kubectl describe role {role_name}
apiGroups, resources, verbs 세 가지를 지정하고, apiGroups와 resources로 지정된 리소스에 대해 verbs 권한을 인가한다.
| 종류 | 개요 |
| * | 모두 처리 |
| create | 생성 |
| delete | 삭제 |
| get | 조회 |
| list | 목록 조회 |
| patch | 일부 업데이트 |
| update | 업데이트 |
| watch | 변경 감시 |
레플리카셋/디폴로이먼트/디플로이먼트의 스케일에 대해 모든 권한을 사용할 수 있는 롤을 기본 네임스페이스로 생성
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: sample-role
namespace: default
rules:
- apiGroups:
- apps
- extensions
resources:
- replicasets
- deployments
- deployments/scale
verbs:
- "*"특정 리소스에 대해서 접근권한을 줄수도 있다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["list“, "get", “create“, “update“, “delete"]
resourceNames: ["blue", "orange"]롤 바인딩 정의
- kubectl get rolebindings
- kubectl describe rolebindings {role_bindings_name}
롤바인딩은 네임스페이스에 연결되는 리소스다. 사용자에 대해 특정 네임스페이스에서 롤 또는 클러스터롤에 정의한 권한을 부여한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: sample-rolebinding
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: sample-role
subjects:
- kind: ServiceAccount
name: sample-serviceaccount
namespace: defaultapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: devuser-developer-binding
subjects:
- kind: User
name: dev-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.io클러스터롤 정의
- kubectl get clusterroles xxx
클러스터롤은 rules에 nonResourceUrls를 지정할 수 있다는 점과 metadata.namespace를 지정할 수 없다는 점(전 네임스페이스에 적용된다)이 일반 롤과 다른점이다. nonResourceUrls는 헬스 체크용 엔드포인트나 버전 정보 표시용 엔드포인트의 URL이다.
모든 네임스페이스의 레플리카셋과 디폴로이먼트에 대해 get을 할 수 있는 권한과 /healthz와 /version의 Get 요청을 할 수 있는 클러스터롤을 생성한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: sample-clusterrole
rules:
- apiGroups:
- apps
- extensions
resources:
- replicasets
- deployments
verbs:
- get
- list
- watch
- nonResourceURLs:
- /healthz
- /healthz/*
- /version
verbs:
- get
클러스터롤의 Aggregation
클러스터롤에만 여러 클러스터롤의 정의를 읽어오는 Aggregation 기능이 있다. Aggregation은 클러스터롤에 정의된 레이블을 기반으로 이루어지며, 집계되는 쪽 클러스터롤에 정의된 롤은 반영되지 않는다.
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: sub-clusterrole1
labels:
app: sample-rbac
rules:
- apiGroups: [""]
resources: ["deployments"]
verbs: ["get"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: sub-clusterrole2
labels:
app: sample-rbac
rules:
- apiGroups: [""]
resources: ["services"]
verbs: ["get"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: sample-aggregated-clusterrole
aggregationRule:
clusterRoleSelectors:
- matchLabels:
app: sample-rbac
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get"]클러스터롤 바인딩 정의
클러스터롤바인딩은 네임스페이스에 연결되지 않은 클러스터 수준의 리소스다. 사용자에 대해 모든 네임스페이스에서 클러스터롤로 정의된 권한을 부여한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: sample-clusterrolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: sample-clusterrole
subjects:
- kind: ServiceAccount
name: sample-serviceaccount
namespace: default
유저가 접근 권한이 있는지 확인하고 싶다면?
Check Access
- kubectl auth can-i create deployments
- kubectl auth can-i delete nodes
- kubectl auth can-i create deployments --as dev-user
- kubectl auth can-i create pods --as dev-user --namespaces test
- kubectl auth can-i list storageclasses --as dev
참고
어드미션 컨트롤
어드미션 컨트롤 단계에서는 별도로 그 요청을 허가할지 판단하거나 요청받은 리소스를 변경하여 등록할 수 있다. 따라서 쿠버네티스 클러스터 관리자가 임의의 상태로 수정할 수 있으므로, 리소스의 limit가 등록되어 있지 않을 경우 등록하거나 리소스 쿼터 체크 처리를 이 단계에서 수행할 수 있다.
어드미션 컨트롤은 플러그인 형태로 되어 있어 ResourceQuota, PodSecurityPolicy 등을 제공한다.
Get API groups and resource names
root@controlplane:~# kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
events ev v1 true Event
limitranges limits v1 true LimitRange
namespaces ns v1 false Namespace
nodes no v1 false Node
persistentvolumeclaims pvc v1 true PersistentVolumeClaim
persistentvolumes pv v1 false PersistentVolume
pods po v1 true Pod
podtemplates v1 true PodTemplate
replicationcontrollers rc v1 true ReplicationController
resourcequotas quota v1 true ResourceQuota
secrets v1 true Secret
serviceaccounts sa v1 true ServiceAccount
services svc v1 true Service
mutatingwebhookconfigurations admissionregistration.k8s.io/v1 false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io/v1 false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io/v1 false CustomResourceDefinition
apiservices apiregistration.k8s.io/v1 false APIService
controllerrevisions apps/v1 true ControllerRevision
daemonsets ds apps/v1 true DaemonSet
deployments deploy apps/v1 true Deployment
replicasets rs apps/v1 true ReplicaSet
statefulsets sts apps/v1 true StatefulSet
tokenreviews authentication.k8s.io/v1 false TokenReview
localsubjectaccessreviews authorization.k8s.io/v1 true LocalSubjectAccessReview
selfsubjectaccessreviews authorization.k8s.io/v1 false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io/v1 false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io/v1 false SubjectAccessReview
horizontalpodautoscalers hpa autoscaling/v1 true HorizontalPodAutoscaler
cronjobs cj batch/v1beta1 true CronJob
jobs batch/v1 true Job
certificatesigningrequests csr certificates.k8s.io/v1 false CertificateSigningRequest
leases coordination.k8s.io/v1 true Lease
endpointslices discovery.k8s.io/v1beta1 true EndpointSlice
events ev events.k8s.io/v1 true Event
ingresses ing extensions/v1beta1 true Ingress
flowschemas flowcontrol.apiserver.k8s.io/v1beta1 false FlowSchema
prioritylevelconfigurations flowcontrol.apiserver.k8s.io/v1beta1 false PriorityLevelConfiguration
ingressclasses networking.k8s.io/v1 false IngressClass
ingresses ing networking.k8s.io/v1 true Ingress
networkpolicies netpol networking.k8s.io/v1 true NetworkPolicy
runtimeclasses node.k8s.io/v1 false RuntimeClass
poddisruptionbudgets pdb policy/v1beta1 true PodDisruptionBudget
podsecuritypolicies psp policy/v1beta1 false PodSecurityPolicy
clusterrolebindings rbac.authorization.k8s.io/v1 false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io/v1 false ClusterRole
rolebindings rbac.authorization.k8s.io/v1 true RoleBinding
roles rbac.authorization.k8s.io/v1 true Role
priorityclasses pc scheduling.k8s.io/v1 false PriorityClass
csidrivers storage.k8s.io/v1 false CSIDriver
csinodes storage.k8s.io/v1 false CSINode
storageclasses sc storage.k8s.io/v1 false StorageClass
volumeattachments storage.k8s.io/v1 false VolumeAttachment
Security Context
컨테이너에 대한 보안 설정. 설정가능한 항목은 아래 표와 같다.
| 종류 | 개요 |
| privileged | 특수 권한을 가진 컨테이너로 실행 |
| capabilites | Capabilites의 추가와 삭제 |
| allowPrivilegeEscalation | 컨테이너 실행 시 상위 프로세스보다 많은 권한을 부여할지 여부 |
| readOnlyRootFilesystem | root 파일 시스템을 읽기 전용으로 할지 여부 |
| runAsUser | 실행 사용자 |
| runAsGroup | 실행 그룹 |
| runAsNonRoot | root에서 실행을 거부 |
| seLinuxoptions | SELinux 옵션 |
apiVersion: v1
kind: Pod
metadata:
name: web-pod
spec:
#Globally take effect on all pods
runAsUser: 1000
containers:
- name: ubuntu
image: ubuntu
command: ["sleep", "3600"]
securityContext:
runAsUser: 1000
capabilities:
add: ["MAC_ADMIN"]
drop: ["AUDIT_WRITE"]* Capabilities are only supported at the container level and not at the POD level
Q. What is the user used to execute the sleep process within the 'ubuntu-sleeper' pod?
kubectl exec ubuntu-sleeper -- whoami
> root출처
- [강의] udemy - Certified Kubernetes Administrator
- [책] 쿠버네티스 완벽 가이드(마사야 아오야마 지음, 박상욱 옮김)
'클라우드 컴퓨팅 > 쿠버네티스' 카테고리의 다른 글
| Docker Network (0) | 2021.12.05 |
|---|---|
| Kubernetes Storage (0) | 2021.11.22 |
| Kubernetes TLS/PKI 살펴보기 (0) | 2021.11.08 |
| Kubernetes Monitoring with Prometheus (0) | 2021.10.27 |
| Helm으로 매니페스트 범용화하기 (0) | 2021.10.26 |