누구나 알고 있습니다. 권한 할당은 항상 보안, 유용성 및 유지 관리 노력 사이의 균형입니다. 권한이 매우 관대하게 부여되면 노력이 매우 적고 사용에 장애물이 거의 없습니다. 그러나 보안이 위험합니다. 권한을 아껴서 할당하면 보안은 높아지지만 프로세스가 복잡하고 관리 작업이 많습니다.
RBAC(역할 기반 액세스 제어)를 통해 Kubernetes는 많은 옵션을 제공하며 자세한 내용도 문서화되어 있습니다(https://kubernetes.io/docs/reference/access-authn-authz/rbac/). 아쉽게도 실제 구현을 위한 실용적인 팁은 많지 않습니다. 이 딜레마를 극복하기 위해 Kubernetes sudo 컨텍스트를 사용하여 권한 관리를 위한 간단하지만 효과적인 진입점을 얻을 수 있는 플러그인을 작성했습니다. 이 블로그 기사는 Google Cloud Platform의 관리형 Kubernetes 예제를 사용하여 플러그인 설치 및 클러스터 구성을 설명합니다.
클러스터 내 개발자의 권리
여기에 제시된 솔루션은 애플리케이션이 자신의 비밀과 클러스터의 구성 맵에 대한 읽기 전용 액세스 권한만 가져야 하므로 사람의 권한 부여와 관련이 있습니다. 이는 권한 할당에서 분명합니다. 그러나 개발자에 대한 권한 부여의 경우 사람들의 작업과 역할이 시간이 지남에 따라 변경될 수 있고 권한 부여는 사람들이 부주의한 실수를 저지르는 것을 방지할 수 있기 때문에 훨씬 더 복잡해집니다. 이로 인해 처음에 언급한 높은 유지 관리 노력이 필요합니다.
유지 관리 노력을 최소화하는 솔루션은 모든 개발자에게 동일하고 광범위한 권한을 부여하는 것입니다. 그러나 이로 인해 언제든지 유해한 변경이 실수로 수행될 수 있는 위험이 있습니다. 특히 생산적인 환경에서는 심각한 다운타임과 심지어 데이터 손실로 이어질 수 있습니다.
이 때문에 우리는 Linux의 sudo 명령과 유사하게 명령을 실행하기 위해 일시적으로 추가 권한을 사용하는 접근 방식을 취하기로 결정했습니다.
sudo-context를 사용한 최소 권한 접근 방식 구현
sudo 스타일 권한을 구현하려면 다음 사항을 구현해야 합니다.
- Kubernetes의 가장 기능 활용
- sudo 컨텍스트 설정
- 클러스터에서 권한 할당
이제 이러한 단계를 자세히 설명합니다.
가장 기능 설정
내부적으로 sudo 기능은 Kubernetes API의 “가장” 기능입니다. 다른 사용자, 그룹 또는 서비스 계정으로 명령을 실행할 수 있습니다. 첫 번째 단계는 클러스터에서 sudo 기능을 활성화하는 것입니다. 응용 프로그램에 따라 이를 수행하는 방법이 다릅니다. 궁극적으로 클라이언트 및 클러스터 측에 설치 및 구성하는 방법은 다음과 같습니다.
kubectl-sudo 플러그인
kubectl-sudo 플러그인을 사용하면 더 높은 권한이 필요한 kubectl 명령을 admin 그룹의 구성원으로 명시적으로 실행할 수 있습니다. 이렇게 하면 예를 들어 스크립트가 실행되거나 잘못된 네임스페이스에 있을 때 클러스터에서 리소스를 실수로 변경하거나 삭제할 가능성이 줄어듭니다. 플러그인은 kubectl에서만 작동합니다. 그러나 kubeconfig를 사용하는 다른 도구(helm, fluxctl, k9s 등)는 사용할 수 없습니다. 다음은 플러그인을 사용하는 간단한 예입니다.kubectl sudo get pod
헬름 sudo 플러그인
Helm 차트는 Kubernetes 환경에서 매우 중요합니다. Helm의 기능도 사용할 수 있도록 kubectl-sudo와 유사하게 사용할 수 있는 해당 플러그인을 개발했습니다. kubectl-sudo 플러그인을 사용하는 것과 유사하게 Helm 플러그인에 대한 예제가 있습니다.helm sudo list
더 많은 도구를 위한 sudo 컨텍스트
또는 fluxctl 또는 k9s와 같은 다른 모든 도구의 경우 kubeconfig에서 sudo 컨텍스트를 생성하는 옵션이 있습니다. 그러면 다음과 같이 사용할 수 있습니다.
kubectl --context SUDO-mycontext # Alternative zu kubectl-sudo
kgpo --context SUDO-mycontext # funktioniert auch mit aliases!
helm --kube-context SUDO-mycontext
fluxctl --context SUDO-mycontext
k9s --context SUDO-mycontext # Änderung auch in k9s möglich ":ctx"
특정 도구에 대해 자동 완성 기능이 설치된 경우 사용 가능한 컨텍스트를 자동으로 인식하고 통합할 수 있습니다. Tab 선택하다.
주의: sudo 컨텍스트를 사용할 때 명령이 실행될 네임스페이스를 포함하는지 항상 확인해야 합니다. 기본적으로 컨텍스트를 설정할 때 현재 네임스페이스만 kubeconfig에 저장됩니다. 다른 네임스페이스에서 명령을 실행하려면 매개변수를 사용하여 명시적으로 지정해야 합니다.kubectl --context SUDO-mycontext --namespace mynamespace get secret
sudo 컨텍스트는 항상 매개변수로 전달되어야 합니다. 활성 컨텍스트로 설정해서는 안 됩니다. 영구적인 관리자 권한이 할당되어 우발적인 변경에 대한 보호가 손상될 수 있기 때문입니다. 이는 다음과 유사합니다. sudo su 사용자가 모든 권한을 가지며 위험한 작업으로 인해 중지되지 않는 Linux에서의 명령.
둘 다 kubectl sudo 게다가 helm sudo 그러나 네임스페이스를 매번 지정할 필요는 없습니다. 여기서 명령은 항상 현재 컨텍스트의 현재 네임스페이스에서 실행됩니다. 따라서 Helm 및 kubectl에는 sudo 플러그인을 사용하는 것이 좋습니다.
로컬 도구 설정
이 스크립트는 sudo 컨텍스트를 만드는 데 사용할 수 있습니다. wget -P /tmp/ "https://raw.githubusercontent.com/cloudogu/sudo-kubeconfig/0.1.0/create-sudo-kubeconfig.sh"
chmod +x /tmp/create-sudo-kubeconfig.sh
/tmp/create-sudo-kubeconfig.sh
kubectl --context SUDO-mycontext get pod
필요한 경우 이미 언급한 두 플러그인인 kubectl-sudo 및 helm-sudo를 bash를 통해 설치할 수 있습니다.
선택 사항: kubectl-sudo 설치
sudo bash -c 'curl -fSL https://raw.githubusercontent.com/postfinance/kubectl-sudo/master/bash/kubectl-sudo -o /usr/bin/kubectl-sudo && chmod a+x /usr/bin/kubectl-sudo'
kubectl sudo get pod
선택 사항: helm-sudo 설치
helm plugin install https://github.com/cloudogu/helm-sudo --version=0.0.2
helm sudo list
인가의 기술적 실현
이제 로컬 컴퓨터에서 sudo 기능을 사용하기 위한 전제 조건이 생성되었으므로 권한을 설정해야 합니다. 예시를 통해 기술적 실현을 위한 단계를 보여줍니다. Google Cloud Platform의 관리형 Kubernetes.
RBAC
sudo 기능을 사용하면 이제 사용자, 그룹 및 서비스 계정을 가장하여 명령을 실행할 수 있습니다(가장). “가장”을 통해 더 광범위한 권한을 얻으려면 Kubernetes RBAC(역할 기반 액세스 제어)를 사용하여 권한을 부여받아야 합니다. “가장”은 다음에 의해 실현됩니다.
- kubectl-sudo:
kubectl --as=$USER --as-group=system:masters "[email protected]" - helm-sudo:
helm --kube-as-user ${USER} --kube-as-group system:masters "[email protected]" - 및 create-sudo-kubeconfig.sh:
as-groups: [ system:masters ]
기존 k8s 클러스터에서 사용자에게 가장 기능에 대한 액세스 권한을 부여하려면 두 개의 리소스를 생성해야 합니다.
- 가장 기능을 사용할 수 있는 ClusterRole입니다.
- 이전에 만든 ClusterRole을 사용하도록 개별 사용자 또는 그룹에 권한을 부여하는 ClusterRoleBinding입니다.
# sudoer.yaml
# Creates a ClusterRole which allows to impersonate users,
# groups and serviceaccounts
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: sudoer
rules:
- apiGroups: [""]
verbs: ["impersonate"]
resources: ["users", "groups", "serviceaccounts"]
# cluster-sudoers.yaml
# Allows users to use kubectl sudo on all resources in the cluster
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-sudoers
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: sudoer
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: [email protected]
- apiGroup: rbac.authorization.k8s.io
kind: User
name: [email protected]
현재 ClusterRoleBinding에서 거기에 나열된 모든 sudo는 모든 네임스페이스에 대한 권한을 가집니다. 여러 ClusterRoleBinding을 사용하여 특정 네임스페이스만 승인하는 것도 가능합니다. 예를 들어 서로 다른 팀에 별도의 네임스페이스가 있을 때 좋은 접근 방식입니다. 이렇게 하려면 아래의 ClusterRoleBinding에서 metadata 다른 속성 namespace: namespace-name 나열됩니다.
언뜻 보기에 클러스터에 대한 변경이 이제 익명으로 가능한 것처럼 보일 수 있습니다. 왜냐하면 다른 역할이 가정되기 때문입니다. 그러나 변경한 실제 사용자 주체는 Google Cloud Platform의 감사 로그에서 볼 수 있습니다. 이를 통해 어떤 사용자가 변경했는지 추적할 수 있습니다. 이는 다른 클라우드 공급자의 관리형 클러스터에서도 유사하게 작동합니다.
구글 클라우드 플랫폼(GCP)
방금 설명한 RBAC 및 조정이 GCP에서 효과가 있으려면 먼저 Google Cloud를 통한 원래 승인을 우회해야 합니다.
역할을 수행하는 사람들 Owner, Editor 또는 Kubernetes Engine Admin GCP에서 일반적으로 RBAC에서 명시적으로 허용하지 않더라도 클러스터에서 무엇이든 실행할 수 있습니다. 따라서 IAM에서 사용자 정의 역할은 Kubernetes 클러스터에서만 인증을 허용하는 GCP에서 한 번 생성되어야 합니다. “Kubernetes Engine 인증”이라고 하는 이 역할에는 다음 권한이 할당됩니다.
- 컨테이너.apiServices.get
- 컨테이너.apiServices.list
- 컨테이너.클러스터.겟
- container.clusters.getCredentials
이 역할은 이제 클러스터에 액세스해야 하는 모든 사용자에게 할당됩니다. 그런 다음 다른 권한은 클러스터의 RBAC에 의해 할당됩니다. 역할을 전체 그룹에 할당할 수도 있습니다. 그룹은 GSuite 그룹을 통해 차례로 관리됩니다. 그러나 이렇게 하려면 클러스터를 만들 때 그룹 전파를 활성화해야 합니다(RBAC용 Google 그룹스). 안타깝게도 이 설정은 이미 존재하는 클러스터에 대해 나중에 활성화할 수 없습니다. 이렇게 하려면 다시 빌드해야 합니다.
결론
RBAC와 sudo-context를 사용하면 권한과 보안을 유지하기 위한 노력이 균형을 이룹니다. 한편으로는 각 사람에 대해 권한을 유지할 필요가 없으며 다른 한편으로는 예를 들어 잘못된 네임스페이스에 있기 때문에 원하지 않는 변경의 위험이 크게 줄어듭니다.
다음 시나리오를 살펴보겠습니다. 개발자가 로컬 개발 클러스터에서 배포 변경 사항을 테스트합니다. 근무일에는 GCP의 생산 클러스터에서 사소한 작업이 수행됩니다. 이제 개발자는 로컬 컨텍스트로 다시 전환하는 것을 잊고 하루가 끝날 때 테스트 배포를 삭제하려고 합니다. 이 라인을 따르는 어떤 일이 아마도 이전에 어떤 사람들에게 일어났을 것입니다. 이로 인해 다운타임이 발생하거나 최악의 경우 데이터 손실이 발생할 수 있습니다.
그러나 sudo 컨텍스트 또는 SUDO 플러그인을 사용하여 생산 클러스터에만 변경 사항을 적용할 수 있는 경우 우발적인 삭제는 실패하고 개발자는 자신의 실수를 알아차릴 것입니다. 따라서 우발적인 오류에 대한 민감성이 감소하는 동시에 사용하기 쉽고 구현하기 쉬우며 매우 안전합니다. Cloudogu에서 우리는 RBAC 및 관련 sudo 컨텍스트를 직접 사용해 왔기 때문에 Kubernetes 클러스터에서 훨씬 더 안전하게 작업하고 있습니다.