[CKS] 1-13. Authorization

인가(Authorization): 사용자 및 앱의 클러스터 접근 권한을 관리하여 보안을 강화하고 안정적 운영을 지원하는 핵심 기능입니다.

[CKS] 1-13. Authorization
Photo by Onur Binay / Unsplash

개요

지금까지 누군가 클러스터에 접근하기 위한 Authentication(인증)에 대해 알아봤습니다.

접근 권한을 얻으면 무엇을 할 수 있을지를 정의하는 것을 인가 Authorization이라고 합니다.

Authorization

개발자, 테스터, 다른 관리자, Jenkins, 모니터링 도구와 같은 외부 애플리케이션 등 추가 사용자에게 접근 권한을 부여할 때는 해당 권한을 제한하는 것이 좋습니다. 클러스터 보안을 보장하고 운영 무결성을 유지하기 위해 권한 부여 정책을 사용하여 사용자 권한을 조정해야하며 이를 수행하기 위한 방법을 확인합니다.

Authorization 메커니즘

  • Node
    • kubelet이 노드의 상태 정보를 kube api에 보고합니다.
      • Node Authorizer가 수행합니다.
      • SYSTEM:NODES 그룹의 일부
    • kubelet이 적절한 자격 증명으로 요청을 하면 Node Authorizer는 필요한 권한을 부여합니다.
  • ABAC
    • 특정 사용자 또는 사용자 그룹을 권한 집합과 연결
    • 정책 파일을 생성하여 api server에 전달
    • 각 사용자나 그룹에 대한정책을 생성, 변경될 때마다 kube-apiserver를 재시작해야합니다.
    • 따라서 사용자, 정책 수가 증가할 수록 관리가 어려워집니다.
{"kind": "Policy", "spec": {"user": "dev-user", "namespace": "*", "resource": "pods", "apiGroup": "*"}}
{"kind": "Policy", "spec": {"user": "dev-user-2", "namespace": "*", "resource": "pods", "apiGroup": "*"}}
{"kind": "Policy", "spec": {"group": "dev-users", "namespace": "*", "resource": "pods", "apiGroup": "*"}}
{"kind": "Policy", "spec": {"user": "security-1", "namespace": "*", "resource": "csr", "apiGroup": "*"}}
  • RBAC
    • 사용자나 그룹을 직접 권한으로 연결하는 대신 역할을 생성
    • 사용자의 권한을 변경해야할 때 역할만 수정하며, 모든 업데이트는 연결된 사용자에게 즉시 반영
  • Webhook
    • 내장된 메커니즘이 아닌 외부에서 권한 관리를 위해 사용
    • 사용자 정보와 요청 정보가 포함된 API 호출을 외부 시스템으로 전송하고 API 서버는 외부 결정에 따라 액세스를 허용하거나 거부
  • AlwaysAllow
    • 어떤 인증도 수행하지 않습니다.
  • AlwaysDeny
    • 모든 인증을 거부합니다.

이러한 모드는 kube-apiserver의 authorization mode옵션을 사용하여 설정됩니다.

기본적으로 AlwaysAllow를 사용합니다. 사용하고 싶은 모드를 ,로 구분하여 여러 개를 설정할 수 있습니다. 여러 모드가 구성되면 지정된 순서대로 각각의 모드를 사용하여 승인됩니다.

ExecStart=/usr/local/bin/kube-apiserver \
  --advertise-address=${INTERNAL_IP} \
  --allow-privileged=true \
  --apiserver-count=3 \
  --authorization-mode=Node,RBAC,Webhook \
  --bind-address=0.0.0.0 \
  --enable-swagger-ui=true \
  --etcd-cafile=/var/lib/kubernetes/ca.pem \
  --etcd-certfile=/var/lib/kubernetes/apiserver-etcd-client.crt \
  --etcd-keyfile=/var/lib/kubernetes/apiserver-etcd-client.key \
  --etcd-servers=https://127.0.0.1:2379 \
  --event-ttl=1h \
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \
  --kubelet-client-certificate=/var/lib/kubernetes/apiserver-etcd-client.crt \
  --kubelet-client-key=/var/lib/kubernetes/apiserver-etcd-client.key \
  --service-node-port-range=30000-32767 \
  --client-ca-file=/var/lib/kubernetes/ca.crt \
  --tls-cert-file=/var/lib/kubernetes/apiserver.crt \
  --tls-private-key-file=/var/lib/kubernetes/apiserver.key \
  --v=2

거부가 일어날 때마다 다음 인가 작업이이루어집니다.

모든 모듈이 요청을 거부하면 엑세스 거부, 하나라도 승인된다면 나머지 작업은 건너뜁니다.