웹사이트 검색

Kubernetes의 역할 기반 액세스 제어(RBAC)


이 페이지에서

  1. 전제 조건
  2. 무엇을 할 것인가?\n
  3. 역할, 역할 바인딩, 클러스터 역할, 클러스터 역할 바인딩 개체 파일을 만듭니다.\n
  4. 역할, 역할 바인딩, 클러스터 역할, 클러스터 역할 바인딩 개체를 만듭니다.\n
  5. kubeconfig(config) 파일을 사용하여 사용자에게 액세스 권한을 제공합니다.\n
    1. Kubeconfig 파일 생성 요약

    역할 기반 액세스 제어(RBAC)는 Kubernetes 클러스터의 컴퓨터 또는 네트워크 리소스에 대한 액세스 권한을 할당하는 데 사용됩니다.

    이 도움말에서는 RBAC의 기본 사항을 이해하고 Role, ClusterRole, RoleBinding 및 ClusterRoleBinding 객체를 생성합니다.

    그런 다음 선택한 네임스페이스의 특정 사용자에게 제한된 액세스 권한을 부여하는 kubeconfig 파일을 생성합니다.

    그러나 진행하기 전에 먼저 기본 사항을 이해합시다.

    1. Role 또는 ClusterRole 에는 일련의 권한이 포함되어 있습니다.\n
    2. 역할은 특정 네임스페이스 내에서 권한을 설정하며 ClusterRole은 네임스페이스가 없는 리소스입니다.\n
    3. 역할 바인딩은 역할에 정의된 권한을 사용자 또는 사용자 집합에 부여하는 반면 ClusterRoleBinding은 클러스터 전체에 대한 액세스 권한을 부여합니다.\n
    4. RoleBinding은 동일한 네임스페이스의 모든 역할을 참조할 수 있습니다. 또는 RoleBinding이 ClusterRole을 참조하고 해당 ClusterRole을 RoleBindin의 네임스페이스에 바인딩할 수 있습니다.\n
    5. kubeconfig 파일은 kubectl 명령줄 도구에서 Kubernetes에 대한 액세스를 구성하는 데 사용되는 파일입니다.\n

    RBAC에 대해 자세히 알아보려면 여기에서 Kubernetes의 공식 문서를 참조하세요.

    Note: Refer screenshots to avoid any confusion before executing the commands. (  = user machine)

    전제 조건

    1. 워커 노드가 1개 이상 있는 Kubernetes 클러스터.
      Kubernetes 클러스터를 만드는 방법을 알아보려면 여기를 클릭하세요. 이 안내서는 AWS Ubuntu EC2 인스턴스에서 1개의 마스터와 2개의 노드가 있는 Kubernetes 클러스터를 생성하는 데 도움이 됩니다.\n

    우리는 무엇을 할 것인가?

    1. 역할, 역할 바인딩, 클러스터 역할, 클러스터 역할 바인딩 개체 파일을 만듭니다.\n
    2. 클러스터에서 역할, 역할 바인딩, 클러스터 역할, 클러스터 역할 바인딩 개체를 만듭니다.\n
    3. kubeconfig 파일을 사용하여 사용자에게 액세스 권한을 제공합니다.\n
    4. kubeconfig 파일 생성 요약.

    역할, 역할 결합, 클러스터 역할, 클러스터 역할 결합 개체 파일을 만듭니다.

    pod에 대한 가져오기, 보기 및 나열 액세스 권한을 부여하는 데 사용할 수 있는 "default" 네임스페이스에 역할을 만들기 위한 파일을 만듭니다.

    vim my-role.yml
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      namespace: default
      name: pod-reader
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]

    새 파일을 만들어 "default" 네임스페이스 내에서 사용자 "jane"에게 "pod-reader" 역할을 허용하는 RoleBinding을 만듭니다.

    vim my-role-binding.yml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: read-pods
      namespace: default
    subjects:
    - kind: User
      name: jane
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io

    바인딩 방식에 따라 특정 네임스페이스 또는 모든 네임스페이스에서 보안 비밀에 대한 가져오기, 감시 및 나열 액세스 권한을 부여하는 데 사용할 수 있는 ClusterRole을 생성하는 파일을 만듭니다.

    vim my-cluster-role.yml
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: secret-reader
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]

    새 파일을 생성하여 "manager" 그룹의 모든 사용자가 모든 네임스페이스의 비밀을 읽을 수 있도록 허용하는 ClusterRoleBinding을 생성합니다.

    vim my-cluster-role-binding.yml
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: read-secrets-global
    subjects:
    - kind: Group
      name: manager
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: secret-reader
      apiGroup: rbac.authorization.k8s.io

    역할, 역할 결합, 클러스터 역할, 클러스터 역할 결합 개체를 만듭니다.

    클러스터에서 기존 역할 및 ClusterRole 목록을 가져옵니다.

    kubectl  get roles
    kubectl  get clusterroles

    클러스터에서 기존 RoleBinding 및 ClusterRoleBinding 목록을 가져옵니다.

    kubectl  get rolebinding
    kubectl  get clusterrolebinding

    이제 위의 단계에서 만든 파일을 사용하여 Role, RoleBinding 및 ClusterRole ClusterRoleBinding을 만듭니다.

    kubectl create -f my-role.yml
    kubectl create -f my-role-binding.yml
    kubectl create -f my-cluster-role.yml
    kubectl create -f my-cluster-role-binding.yml

    다음 명령을 사용하여 객체가 생성되었는지 확인합니다.

    kubectl  get roles | grep pod-reader
    kubectl  get rolebinding | grep read-pods
    kubectl  get clusterroles | grep secret-reader
    kubectl  get clusterrolebinding | grep read-secrets-global

    위의 스크린샷에서 Role, RoleBinding 및 ClusterRole, ClusterRoleBinding이 생성된 것을 볼 수 있습니다.

    kubeconfig(config) 파일을 사용하여 사용자에게 액세스 권한을 제공합니다.

    이제 이 섹션에서는 사용자와 공유할 수 있는 구성 파일을 생성합니다. 여기에서 이 시나리오를 테스트하기 위해 Linux 서버에서 "bob" 사용자를 생성하고 이 구성 파일을 "bob" 사용자와 공유합니다. 그런 다음 해당 사용자에게 허용되거나 허용되지 않는 작업을 수행하려고 시도합니다. 관리자 ClusterRole을 "bob" 네임스페이스 내의 모든 개체에 대한 액세스 권한을 부여하는 "bob" 사용자에 바인딩합니다.

    마스터 노드에서 openssl을 사용하여 키 및 인증서 서명 요청(CSR)을 생성합니다.

    pwd
    mkdir user-bob
    cd user-bob/
    openssl req -new -newkey rsa:4096 -nodes -keyout bob-k8s.key -out bob-k8s.csr -subj "/CN=bob/O=devops"
    cat bob-k8s.csr | base64 | tr -d '\n'

    위 단계에서 생성한 CSR을 포함하는 CertificateSigningRequest 개체 정의 파일을 만듭니다. 아래 파일에서 "cat bob-k8s.csr | base64 | tr -d 출력을 추가합니다.\n\ 명령을 \요청\ 속성으로

    vim k8s-csr.yaml
    apiVersion: certificates.k8s.io/v1beta1
    kind: CertificateSigningRequest
    metadata:
      name: bob-k8s-access
    spec:
      groups:
      - system:authenticated
      request: # replace output of: cat bob-k8s.csr | base64 | tr -d '\n'
      usages:
      - client auth
    cat k8s-csr.yaml

    위 단계에서 생성한 CSR을 포함하는 Kubernetes 내에서 CertificateSigningRequest 객체를 생성합니다.

    kubectl  get csr
    kubectl  create -f k8s-csr.yaml
    kubectl  get csr

    이제 위 단계에서 생성한 CSR(CertificateSigningRequest) 개체를 승인하려고 합니다.

    kubectl  get csr
    kubectl certificate approve bob-k8s-access
    kubectl  get csr

    위 스크린샷에서 CSR이 승인, 발급되었음을 확인할 수 있습니다.

    CSR 개체의 'status.certificate' 필드에서 사용 가능한 인증서를 검색합니다.

    ls -lt
    kubectl get csr bob-k8s-access -o jsonpath='{.status.certificate}' | base64 --decode > bob-k8s-access.crt
    ls -lt
    cat bob-k8s-access.crt

    Bob의 kubeconfig 파일에 대한 다음 요구사항인 클러스터 CA 인증서를 검색하여 "k8s-ca.crt" 파일에 저장합니다.

    ls -lt
    kubectl config view -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' --raw | base64 --decode - > k8s-ca.crt
    ls -lt
    cat k8s-ca.crt

    Bob의 kubeconfig 파일에서 클러스터 구성을 설정합니다. 이러한 모든 세부정보는 아래 명령어를 사용하여 기존 kubeconfig에서 가져옵니다.

    ls -lt
    kubectl config set-cluster $(kubectl config view -o jsonpath='{.clusters[0].name}') --server=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}') --certificate-authority=k8s-ca.crt --kubeconfig=bob-k8s-config --embed-certs
    ls -lt
    cat bob-k8s-config

    Bob의 키와 인증서를 구성 파일로 가져올 사용자를 설정합니다.

    ls -lt
    kubectl config set-credentials bob --client-certificate=bob-k8s-access.crt --client-key=bob-k8s.key --embed-certs --kubeconfig=bob-k8s-config
    ls -lt
    cat bob-k8s-config

    다음 명령을 사용하여 "Bobs" 구성 파일에 대한 컨텍스트를 만듭니다.

    ls -lt
    kubectl config set-context bob --cluster=$(kubectl config view -o jsonpath='{.clusters[0].name}') --namespace=bob --user=bob --kubeconfig=bob-k8s-config
    ls -lt
    cat bob-k8s-config

    Bob의 네임스페이스 만들기

    kubectl  get ns
    kubectl create ns bob
    kubectl  get ns -o wide
    kubectl label ns bob user=bob env=sandbox
    kubectl  get ns -o wide

    Bob이 kubectl 명령에 사용할 컨텍스트를 지정합니다.

    cat bob-k8s-config
    kubectl config use-context bob --kubeconfig=bob-k8s-config
    cat bob-k8s-config

    "bob-k8s-config"를 마스터 노드에서 Bobs 홈 디렉터리의 ".kube/config" 파일로 복사하고 'kubectl 버전'을 실행하여 Bob의 kubeconfig를 테스트합니다.

    vim .kube/config #All the output of "cat bob-k8s-config" command ran on the master node and save it to /home/bob/.kube/config on the user machine.
    kubectl version #Execute this on the user machine

    사용자 머신에서 다음 명령어를 실행하여 권한을 테스트합니다.

    kubectl  get nodes
    kubectl  get pods
    kubectl  get ns
    kubectl  get deployments
    kubectl  get all

    위의 스크린샷에서 "Bob" 사용자에게 액세스 권한이 부여되지 않았기 때문에 어떤 작업도 수행할 수 없음을 볼 수 있습니다.

    기본 '관리자' 클러스터 역할을 Bob에게 할당하여 Bob의 네임스페이스 내에서 대부분의 Kubernetes 객체 유형을 만듭니다. 이 "bob-admin" 역할은 "admin" ClusterRole을 사용하여 "bob" 네임스페이스의 "Bob" 사용자에게 관리자 액세스 권한을 부여합니다.

    마스터 노드에서 다음 명령을 실행합니다.

    kubectl create rolebinding bob-admin --namespace=bob --clusterrole=admin --user=bob 
    kubectl  get rolebinding
    kubectl  get clusterrole | grep  admin

    Bob에게 생성된 네임스페이스를 가져옵니다.

    이제 사용자 시스템에서 다음 명령을 모두 실행하십시오.

    kubectl  get ns
    kubectl  get ns bob

    위의 스크린샷에서 "Bob" 사용자가 "네임스페이스" 리소스를 나열할 수 없음을 볼 수 있습니다.

    Bobs kubeconfig 파일에서 기본 네임스페이스로 설정된 \bob\ 네임스페이스에 포드를 만듭니다.

    kubectl  run nginx --image=nginx
    kubectl  get pods
    kubectl  get pods -o wide

    기본 네임스페이스로 설정된 현재 네임스페이스 확인

    kubectl config get-contexts

    위 스크린샷에서 "bob"에 대해 "admin" 역할을 "Bob" 사용자에게 바인드했기 때문에 "Bob"이 "bob" 네임스페이스에 포드를 생성할 수 있음을 볼 수 있습니다. 네임스페이스.

    Bob에게 권한이 없는 "기본" 네임스페이스에 포드를 생성해 보십시오. "Bob" 사용자가 "bob" 네임스페이스에서만 개체를 생성할 수 있도록 허용했기 때문에 Bob 사용자는 "bob" 이외의 네임스페이스에서 리소스를 생성할 수 없습니다.

    kubectl  run nginx-2 --image=nginx --namespace=default

    kubeconfig 파일에서 기본 네임스페이스로 설정된 네임스페이스를 확인합니다. 이것은 \bob\ 네임스페이스가 구성 파일에서 기본 네임스페이스로 설정되었음을 보여줍니다.

    kubectl config view --minify | grep namespace:

    Kubeconfig 파일 생성 요약

    1. openssl을 사용하여 키 및 인증서 서명 요청(CSR)을 만듭니다.\n
    2. CertificateSigningRequest 개체 정의 파일을 만듭니다.
    3. CertificateSigningRequest 개체를 만듭니다.
    4. CSR(CertificateSigningRequest)을 승인합니다.\n
    5. CSR 객체의 인증서를 검색합니다.\n
    6. 클러스터 CA 인증서를 검색합니다.\n
    7. kubeconfig 파일에서 클러스터 구성을 설정합니다.\n
    8. 사용자를 설정합니다.\n
    9. 컨텍스트를 만듭니다.
    10. 사용자를 위한 네임스페이스를 만듭니다.\n
    11. kubeconfig 파일에서 컨텍스트를 지정합니다.\n
    12. kubeconfig를 사용자에게 전달합니다.\n
    13. 사용자 구성 파일을 사용하여 권한을 테스트합니다.\n
    14. 사용자에게 역할 할당\n
    15. 사용자 구성 파일을 사용하여 권한을 다시 테스트합니다.\n

    결론

    이 문서에서는 Role, RoleBinding 및 ClusterRole, ClusterRoleBinding의 기본 사항을 살펴보았으며 이러한 객체도 클러스터에 생성했습니다. 그런 다음 특정 사용자가 특정 네임스페이스에서 작업을 수행할 수 있도록 하는 구성 파일을 만들었습니다. RBAC가 Kubernetes 클러스터에 대한 액세스를 제한하는 데 어떻게 도움이 되는지 확인했습니다.