콘텐츠로 이동

보안 및 개인정보 보호

Kubetail은 로그 데이터를 클러스터에서 데스크톱까지 사용자의 통제 아래에 두고, 누가 그 데이터에 접근할 수 있는지는 클러스터 관리자가 계속 통제할 수 있도록 설계되었습니다. 이 페이지에서는 Kubetail이 설계 차원에서 어떻게 개인정보 보호와 보안을 처리하는지 설명합니다.


Kubetail에는 클라우드 로그 백엔드가 없기 때문에, 로그를 볼 때 데이터는 외부 서비스를 먼저 거치지 않고 클러스터에서 사용자 기기로 직접 이동합니다. 경로는 배포 토폴로지에 따라 달라집니다.

  • 데스크톱: 로그는 디스크 위의 Pod 로그 파일에서 시작해 kube-apiserver(또는 설치되어 있다면 Kubetail API)를 거쳐 로컬 머신에서 실행 중인 Dashboard 서버로 전달되고, 마지막으로 브라우저에 도달합니다. 전체 경로가 클러스터와 데스크톱 내부에 머뭅니다.
  • 클러스터: 로그는 디스크 위의 Pod 로그 파일에서 시작해 kube-apiserver(또는 Kubetail API)를 거쳐 클러스터 내부에서 실행 중인 Dashboard 서버로 전달됩니다. 이 모든 과정은 클러스터 내부 네트워크를 통해 이뤄집니다. kubectl port-forward, kubectl proxy, 또는 사용자가 제어하는 ingress로 연결한 이후에만 로그가 브라우저에 도달합니다.

어느 경우든 로그 데이터는 처음부터 끝까지 사용자의 통제 아래에 있습니다(자세한 내용은 아키텍처를 참고하세요).


Kubetail은 모든 접근 제어를 Kubernetes RBAC에 위임하므로, 클러스터 관리자는 누가 어떤 로그를 볼 수 있는지에 대해 완전한 통제권을 유지합니다.

데스크톱에서 Kubetail은 활성 kubeconfig context의 RBAC 권한을 그대로 상속받습니다. 즉 kubectl이 사용하는 것과 동일한 권한입니다. 사용자가 어떤 Pod에 대해 kubectl logs를 실행할 수 있다면, Kubetail에서도 그 로그를 볼 수 있습니다. 그렇지 않다면 Kubetail은 요청을 거부합니다.

Kubetail은 로그 스트림을 열기 전에 Kubernetes SelfSubjectAccessReview API를 사용해 권한을 확인합니다. 클러스터 관리자는 표준 Kubernetes RBAC 리소스를 사용해 필요한 만큼 세밀하게 접근 범위를 제한할 수 있습니다.

선택 사항인 Kubetail API가 클러스터에 설치되어 있으면, Dashboard 서버에서 Cluster API로 향하는 모든 요청에는 사용자의 Kubernetes service account token이 포함됩니다. Cluster API와 Cluster Agent는 데이터를 제공하기 전에 둘 다 이 토큰을 Kubernetes authorization API에 대조해 검증합니다.

즉, Kubetail API를 통한 로그 접근은 다른 Kubernetes API 작업과 동일한 RBAC 정책의 적용을 받습니다. 별도의 권한 시스템이 추가되지 않습니다. 특정 namespace에서 pods/log에 대한 getwatch 권한이 없는 사용자는 어떤 방식으로 연결하더라도 그 namespace의 로그 데이터를 받을 수 없습니다.


속성동작
로그 데이터가 사용자 환경을 벗어남절대 아님
클라우드 로그 백엔드없음
접근 제어 메커니즘Kubernetes RBAC
인증 방식(데스크톱)kubeconfig 자격 증명
인증 방식(클러스터)Kubernetes service account token