이 문서에서는 Connect에서 기본 제공되는 보안 조치에 대해 설명합니다.
효과적인 하이브리드 및 멀티 클라우드 플랫폼은 다양한 환경에서 중앙 관리, 관찰 기능, 서비스 액세스 권한을 제공합니다. GKE Enterprise는 사용자가 활용하는 Kubernetes 공급자와 상관없이 이러한 기능 전반에서 일관되고 포괄적인 환경을 제공합니다. Connect는 규모의 경제로 공급자 전반에서 다음을 제공하는 가벼운 에이전트입니다.
- 멀티 클러스터 관리 및 클러스터 가시성
- 애플리케이션 서비스 배포 및 수명 주기 관리
이 문서에서는 다음 사항에 대해 설명합니다.
- Connect의 설계가 보안을 최우선시하는 방법
- Connect 에이전트 배포 권장사항
- Kubernetes 배포 보안 상태 개선 방법
Connect 아키텍처
Connect를 사용하면 최종 사용자와 Google Cloud 서비스가 공개 인터넷에 연결되어 있지 않은 Kubernetes API 서버에 액세스할 수 있습니다. Connect 에이전트는 Kubernetes 클러스터에서 실행되며(클러스터당 1개의 에이전트) Connect 프록시에 연결됩니다. Kubernetes 클러스터와 상호작용해야 하는 Google Cloud 서비스는 요청을 에이전트에 전달하는 프록시에 연결됩니다. 그 다음에 에이전트는 다음 다이어그램에 설명된 대로 Kubernetes API 서버에 전달합니다.
에이전트가 배포되면 Google Cloud에 영구적인 TLS 1.2+ 연결을 설정하여 요청을 대기합니다. 관리자가 사용 설정하면 Google Cloud 서비스는 Kubernetes 클러스터에 대한 요청을 생성할 수 있습니다. 이러한 요청은 Google Cloud 콘솔, Connect Gateway 또는 기타 Google 서비스와의 직접적인 사용자 상호작용에서 발생할 수도 있습니다.
Google Cloud 서비스는 프록시에 요청을 보냅니다. 그런 다음 프록시는 클러스터를 담당하는 배포된 에이전트로 요청을 전달하고, 마지막으로 에이전트는 요청을 Kubernetes API 서버에 전달합니다. Kubernetes API 서버는 Kubernetes 인증, 승인, 감사 로깅 정책을 적용하고 응답을 반환합니다. 응답은 에이전트와 프록시를 통해 Google Cloud 서비스로 다시 전달됩니다. 프로세스의 각 단계에서 구성요소는 연결별, 요청별로 인증 및 승인을 수행합니다.
Kubernetes API 서버는 Connect를 통한 요청을 포함하여 모든 요청에 동일한 인증, 승인, 감사 로깅 정책을 적용합니다. 이 프로세스를 통해 상시로 클러스터에 대한 액세스를 제어할 수 있습니다.
Connect 및 심층 방어
심층 방어는 Google Cloud가 인프라 내에서 보안 권장사항에 따라 수행하는 모든 작업에 내재되어 있습니다. Google에서는 중요한 데이터, 정보, 사용자를 보호하기 위해 조직과 고객의 보안을 유지하는 모든 측면에 계층화된 접근 방식을 취합니다. 이는 Connect를 설계한 원칙과 동일합니다.
Google의 심층 방어 전략 및 설계 외에도 보안 수준 및 표준에 따라 여기에 제공된 콘텐츠를 평가해야 합니다. 이 섹션에서는 Kubernetes 강화 권장사항을 보완하여 취할 수 있는 추가 조치를 소개합니다.
구성요소 간 보안
Connect 요청의 각 구성요소는 피어를 인증하고 다음 다이어그램과 같이 해당 데이터에 대해 인증 및 승인된 피어와만 데이터를 공유합니다.
Connect 요청의 각 구성요소는 다음을 사용하여 서로를 인증합니다.
- 전송 계층 보안(TLS)
- 애플리케이션 레이어 전송 보안(ALTS)
- OAuth
Connect 요청의 각 구성요소는 다음을 사용하여 서로를 승인합니다.
- Identity and Access Management(IAM)
- 허용 목록
Kubernetes 클러스터와 Google Cloud 간의 연결은 암호화되며, 각 연결에서 최소한 1개의 피어는 인증서 기반 인증을 사용합니다. 이 프로세스는 모든 토큰 사용자 인증 정보가 전송 중에 암호화되고 인증되고 승인된 피어에 의해서만 수신되도록 보장합니다.
Google Cloud에 대한 사용자 인증
Google Cloud Console을 사용할 때 사용자는 표준 Google 로그인 흐름을 거칩니다. Google Cloud는 사용자의 브라우저에서 인증하는 TLS 인증서를 제공하며, 사용자는 Google Cloud 또는 Google Workspace 계정에 로그인하여 Google Cloud에 인증합니다.
Google Cloud 콘솔이나 다른 API를 통한 프로젝트 액세스는 IAM 권한에 의해 제어됩니다.
Google Cloud 서비스 간 인증
Google Cloud는 내부 서비스 간 인증에 ALTS를 사용합니다. ALTS를 사용하면 프록시와 같은 Google Cloud 서비스에서 인증된 무결성 보호 연결을 만들 수 있습니다.
프록시는 서비스 ID 허용 목록을 사용하여 액세스를 제한하므로 프록시를 사용하여 원격 Connect 인스턴스에 연결할 수 있도록 Google Cloud 서비스를 내부적으로 승인해야 합니다.
Google Cloud 인증
에이전트는 TLS를 사용하여 각 연결을 인증하고 암호화합니다. 에이전트는 바이너리에 구축된 루트 인증서를 사용해 Google Cloud TLS 인증서를 인증하여 실수로 에이전트의 컨테이너에 추가된 인증서를 신뢰하지 않도록 합니다. 에이전트는 올바르게 인증된 엔드포인트에 대해서만 API 호출을 실행합니다. 이 프로세스를 통해 Google Cloud에서 서비스 계정 인증서와 Kubernetes API 요청을 보내고 응답은 Google Cloud로만 전송됩니다.
에이전트가 정상 작업 중에 통신하는 도메인 목록은 네트워크 연결 확인을 참조하세요.
HTTP 프록시를 통해 Google Cloud에 연결하도록 에이전트를 구성할 수 있습니다. 이 구성에서 에이전트는 HTTP 프록시에 대해 HTTP/1.1
CONNECT를 사용하고 Google Cloud에 TLS 연결을 설정합니다. HTTP 프록시는 에이전트와 Google Cloud 간의 암호화된 트래픽만 허용합니다. 에이전트와 Google Cloud 간 연결의 엔드 투 엔드 무결성 및 보안은 영향을 받지 않습니다.
에이전트 인증
에이전트는 사용자가 만든 Google Cloud 서비스 계정을 사용하여 Google Cloud에 인증합니다. 클러스터 관리자는 에이전트를 배포할 때 이 서비스 계정의 비공개 키를 제공하고 키의 개인정보 보호를 담당합니다. 에이전트가 Google Cloud에 연결되면 이 서비스 계정으로 인증하고 구성된 프로젝트의 요청을 수신하도록 요청합니다.
Google Cloud는 서비스 계정 사용자 인증 정보를 인증하고 Google Cloud 서비스 계정에 프로젝트의 gkehub.endpoints.connect IAM 권한이 있는지 확인합니다. 일반적으로 이 권한은 gkehub.connect 역할을 통해 부여됩니다. 이 권한이 없으면 에이전트의 요청이 거부되고 Google Cloud에서 요청을 수신할 수 없습니다.
Kubernetes API 서버
에이전트는 Kubernetes 클라이언트 라이브러리를 사용하여 Kubernetes API 서버와 TLS 연결을 만듭니다. Kubernetes 런타임은 에이전트가 API 서버를 인증하는 데 사용하는 TLS 인증 기관(CA) 인증서를 에이전트의 컨테이너에 제공합니다.
API 서버는 다음 섹션의 설명대로 각 요청을 개별적으로 인증합니다.
보안 요청
Google Cloud에서 Connect를 통해 전송되는 각 요청에는 요청의 발신자, 즉 요청을 생성한 Google Cloud 서비스와 요청이 전송된 최종 사용자(해당되는 경우) 모두를 식별하는 사용자 인증 정보가 포함됩니다. 이러한 사용자 인증 정보를 통해 Kubernetes API 서버는 각 요청에 대한 승인 및 감사 제어를 제공할 수 있습니다.
서비스와 에이전트 간 인증
에이전트에 전송된 각 요청에는 다음 다이어그램과 같이 요청을 전송한 Google Cloud 서비스를 식별하는 단기 토큰이 포함됩니다.
토큰은 Google Cloud 서비스에만 연결된 Google Cloud 서비스 계정에서 서명합니다. 에이전트는 토큰의 유효성을 검사하기 위해 서비스 계정의 공개 키를 가져옵니다. 이 토큰은 API 서버로 전달되지 않습니다.
에이전트는 바이너리에 포함된 CA 루트를 사용하여 Google Cloud 인증서의 유효성을 검사합니다. 이 프로세스를 통해 Google Cloud에서 신뢰할 수 있고 변경되지 않는 요청을 수신할 수 있습니다.
최종 사용자 인증
사용자를 대신하여 클러스터에 액세스하는 Google Cloud 서비스는 다음 다이어그램과 같이 API 서버에 인증하기 위해 해당 사용자의 사용자 인증 정보가 필요합니다.
이 정책은 Connect를 통해 액세스할 때 동일한 권한을 사용자에게 적용하는 데 도움이 됩니다. 일부 Google Cloud 서비스는 사용자를 대신하여 API 서버에 인증합니다. 예를 들어 사용자는 Google Cloud Console에 액세스하여 Fleet 등록 클러스터의 워크로드를 볼 수 있습니다. 사용자는 이러한 서비스에 액세스할 때 Kubernetes API 서버가 인식하는 사용자 인증 정보, 즉 Kubernetes API 서버가 지원하는 모든 토큰을 제공합니다.
Google Cloud Console은 이러한 사용자 인증 정보를 사용자 프로필의 일부로 저장합니다. 사용자 인증 정보는 저장 상태에서 암호화되며 사용자의 Google Cloud 또는 Google Workspace 사용자 인증 정보로만 액세스할 수 있으며 Connect를 통한 연결에만 사용됩니다. 이러한 사용자 인증 정보는 다시 다운로드할 수 없습니다. 사용자 인증 정보는 사용자가 클러스터에서 로그아웃할 때, 클러스터 등록이 Google Cloud에서 삭제될 때, 프로젝트가 삭제될 때 또는 사용자 계정이 삭제될 때 삭제됩니다. 자세한 내용은 Google Cloud에서 데이터 삭제를 참조하세요.
사용자가 Google Cloud Console과 상호작용할 때 Kubernetes API 서버에 대한 요청이 생성됩니다. 서비스는 Connect를 통해 요청과 함께 사용자 인증 정보를 전송합니다. 그런 다음 에이전트가 요청과 사용자 인증 정보를 Kubernetes API 서버에 제공합니다.
Kubernetes API 서버는 사용자의 사용자 인증 정보를 인증하고 사용자 ID에 대한 승인을 수행하며 작업에 대한 감사 이벤트를 생성하고(구성된 경우) 결과를 반환합니다. 사용자가 제공한 사용자 인증 정보는 요청을 인증하는 데 사용되므로 Kubernetes API 서버는 Connect에 다른 요청과 동일한 승인 및 감사 정책을 적용합니다.
서비스와 Kubernetes 간 인증
사용자 컨텍스트 외부에서 Kubernetes API 서버에 액세스하는 Google Cloud 서비스는 Kubernetes 명의 도용을 사용하여 Kubernetes API 서버에 인증합니다. 이 메서드를 사용하면 Kubernetes API 서버에서 다음 다이어그램과 같이 서비스별 승인 확인 및 감사 로깅을 제공할 수 있습니다.
Google Cloud의 서비스는 사용자 컨텍스트 외부에서 Connect를 사용할 수 있습니다. 예를 들어 멀티 클러스터 인그레스 서비스는 클러스터 간에 인그레스 리소스를 자동으로 동기화할 수 있습니다. 이러한 서비스에는 Kubernetes API 서버가 인증할 수 있는 사용자 인증 정보가 없습니다. 대부분의 API 서버는 Google Cloud 서비스의 사용자 인증 정보를 인증하도록 구성되지 않습니다. 하지만 API 서버는 명의 도용을 통해 다른 서비스에 제한된 인증 권한을 위임할 수 있으며 에이전트는 Connect를 통해 요청을 전송하는 Google Cloud 서비스를 인증할 수 있습니다. 이렇게 하면 에이전트를 통한 요청을 Google Cloud 서비스 계정으로 인증할 수 있습니다.
Google Cloud 서비스가 사용자의 컨텍스트가 아닌 자체적으로 요청을 전송하면 에이전트는 Google Cloud 서비스를 식별하는 Kubernetes 사용자 인증 정보 및 Kubernetes 명의 도용 헤더를 요청에 추가합니다. 명의 도용 헤더는 에이전트가 인증한 Google Cloud 서비스 계정의 사용자 이름을 요구합니다.
Kubernetes API 서버는 에이전트의 사용자 인증 정보를 인증하고 에이전트가 Google Cloud 서비스 계정을 명의 도용할 수 있는지 확인합니다. 일반적으로 명의 도용 기능은 역할 기반 액세스 제어(RBAC) 규칙에 의해 제어되며 Google Cloud 서비스 계정과 같은 특정 ID로 제한될 수 있습니다.
에이전트가 요청된 ID를 명의 도용하도록 승인되면 API 서버는 Google Cloud 서비스 계정에 대해 승인 확인을 수행하고 요청을 처리합니다. 요청의 감사 로그에는 에이전트의 ID와 명의 도용된 Google Cloud 서비스 계정이 모두 포함됩니다.
클러스터 내 보안
에이전트는 궁극적으로 다음 다이어그램과 같이 Kubernetes API 요청을 Kubernetes API 서버로 전송합니다.
Kubernetes API 서버는 다른 요청을 처리할 때처럼 이러한 요청을 인증 및 승인하고 감사를 로깅합니다.
이러한 요청에 대한 프록시로 에이전트는 사용자 인증 정보, 요청, 응답과 같은 민감한 정보에 액세스할 수 있습니다. Kubernetes 및 Kubernetes 생태계는 다른 작업 수행자가 해당 액세스 권한을 얻지 못하도록 하여 에이전트가 필요한 정보에만 액세스하도록 보장하는 도구를 제공합니다.
Kubernetes 인증
Kubernetes API 서버는 각 수신 요청의 발신자를 인증하여 승인 단계에서 적용할 권한을 결정합니다. 앞서 설명한 것처럼 요청은 사용자의 사용자 인증 정보를 포함하거나 에이전트의 Kubernetes 사용자 인증 정보 및 명의 도용 헤더를 포함합니다.
클러스터 관리자는 Kubernetes API 서버가 인식하는 인증 메커니즘을 계속 제어합니다. 관리자는 사용자의 사용자 인증 정보를 취소하고 에이전트의 사용자 인증 정보의 권한을 취소하거나 줄일 수 있습니다.
Kubernetes 승인
Kubernetes API 서버는 인증된 ID가 요청된 리소스에서 요청된 작업을 수행할 수 있는지 확인합니다.
클러스터 관리자는 Kubernetes 승인 메커니즘을 사용하여 승인 규칙을 구성할 수 있습니다. Connect는 클러스터를 대신하여 승인 확인을 수행하지 않습니다.
에이전트 보안
에이전트는 전달하는 사용자 인증 정보, 요청, 응답뿐 아니라 자체적인(Kubernetes 및 Google Cloud) 사용자 인증 정보에 액세스할 수 있습니다. 따라서 에이전트는 연결된 클러스터에서 신뢰성을 갖습니다.
에이전트는 다음과 같은 보안 핵심 요소로 설계되었습니다.
- 에이전트는 가비지 컬렉션 메모리 관리 기능을 제공하고 안전하지 않은 많은 메모리 작업을 방지하는 Go로 작성됩니다.
- 에이전트는 distroless 컨테이너 이미지에 배포됩니다. 에이전트의 이미지에는 에이전트의 실행 경로와 관련이 없는 셸, libc 또는 기타 코드가 포함되어 있지 않습니다.
- 에이전트의 이미지는 체크인 코드에서 Google의 공유 빌드 인프라로 구축됩니다. 이 빌드 시스템만 Container Registry에 에이전트 이미지를 배포할 수 있습니다. Google Cloud 개발자는 자체적으로 새 이미지를 배포할 수 없습니다. 이 프로세스를 통해 에이전트 소스의 모든 수정 사항을 부인 방지를 위해 작성자와 검토자까지 추적할 수 있습니다.
에이전트는 클러스터를 등록할 때 배포되는 Kubernetes 클러스터에서 표준 배포로 실행됩니다.
따라서 배포, ReplicaSets, 포드의 모니터링 및 보안에 사용할 수 있는 모든 옵션 및 권장사항을 에이전트에 사용할 수 있습니다.
이러한 메커니즘은 에이전트 컨테이너를 손상시키기 어렵도록 설계되었습니다. 하지만 에이전트 노드에 대한 권한이 있는 액세스는 에이전트의 환경을 손상시킬 수 있으므로 관리자는 클러스터 인프라를 보호하기 위해 표준 Kubernetes 보안 지침을 준수해야 합니다.
VPC 서비스 제어를 통한 데이터 보안
VPC 서비스 제어는 Identity and Access Management(IAM)과 별개로 Google Cloud 서비스의 보안을 더욱 강화합니다. IAM은 세분화된 ID 기반 액세스 제어를 지원하지만 VPC 서비스 제어는 경계 간 데이터 이그레스 제어를 포함한 보다 광범위한 컨텍스트 기반 경계 보안을 지원합니다. 예를 들어 특정 프로젝트만 BigQuery 데이터에 액세스할 수 있도록 지정할 수 있습니다. VPC 서비스 제어를 실행하여 데이터를 보호하는 방식은 VPC 서비스 제어 개요에서 확인할 수 있습니다.
지정된 서비스 경계 내에서 Connect를 사용하는 데 필요한 서비스에 액세스할 수 있는지 확인되면 추가 데이터 보안을 위해 Connect와 함께 VPC 서비스 제어를 사용할 수 있습니다. Connect 기본 요건에서 자세히 알아보세요.