153-162

KubeConfig

kubectl gert pods --server ~
--> kubectl config 파일로 이동

kubectl get pods --kubeconfig -> $HOME/.kube/config

$HOME/.kube/config

yaml 포맷

• Clusters
• Contexts 어떤 사용자가 어떤 클러스터에 접근 하는지 Admin@Production
  기존유저 사용 기존클러스터 사용
• Users

파일은 kubectl에 의해 참조 됨
current-context로 현재 컨텍스트 지정 가능

현재 컨텍스트 확인
kubectl config view

kubectl config view --kubeconfig=my-config

컨텍스트 업데이트

kubectl config use-context user@production
-> 파일에 반영 됨

kubectl config -h

특정 네임스페이스를 위한 컨텍스트도 생성 가능
contexts.namespace 추가

API Groups

/version /api /healthz /logs /apis /metrics

/api /apis

/api core -> /v1 -> ns, pods, rc...
/apis named -> 좀더 조직화 되어 있음 /apps /extensions /storage.k8s.io
api groups와 그 아래에 resources로 구성되어 있음

curl ~:6443 -k | grep "name" 에서 확인 가능

kubectl proxy -> curl http//~:8001 -k

kube proxy 와 kubectl proxy는 다름

쿠버네티스의 모든 리소스는 api그룹으로 그룹화 되어 있음

Authorization

Why Authorization?
클러스터에 액세스할 계정을 따로 만듬 => TLS 인증서나 서비스어카운트

쿠버네티스에서 제공하는 인증 방법

• node
  사용자에 의해 클러스터 액세스, kubelet도 api로 요청 -> 노드 Authorization에 의해
  ex - system:node:node01 in 인증서
• abac
  api외부 인증 -> 개발자가 파드 생성 및 삭제, 다른 개발자가 파드 생성 및 삭제.. 등
• rbac
  역할기반 인증 관리 -> 역할을 만들고 사용자를 연결함 -> 관리가 쉬움
• webhook
  외부에서 권환을 관리하고 싶을때

AlwaysAllow, AlwaysDeny

설정법

kubeapi.yaml -> authorization-mode에서 설정 가능
지정한 순서대로 모드 처리가 진행 됨 -> 모듈이 거절 할때마다 다음 모듈로 넘어감

Role Based Access Controls

역할 기반 접근 제어
Role이라는 리소스를 생성 가능

kind: Role
...
rules:
  - apiGroups: [""]
    resources: ["Pods"] 해당 리소스에 대한
    verbs: ["list", "get"] 가능한 명령

생성 후에 사용자를 연결 -> 롤 바인딩

kind: RoleBinding

subjects: 사용자 세부 정보

roleRef: -> 만든 롤 연결

kbectl get roles
kubectl get rolebindings
kubectl describe role dev
kubctl describe rolebindg dev-bind

check access

kubectl auth can-i create deploy
kubectl auth can-i delete nodes
kubectl auth can-i create deploy --as dev-user
kubectl auth can-i create deploy --as dev-user --namespace test

네임스페이스가 5개 있을때 파드 접근이 가능하지만 특정 네임스페이스의 파드에만 접근해야할때
Role의 resoucreNames에 지정하면 제어 가능