• 개발
  • 아키텍처
  • 클라이언트 라이브러리
  • 성능 고려 사항
  • 테스트
  • Amazon EKS 통합
• 보안
  • 서버 측 요청 위조(SSRF) 공격
• Kubernetes 통합 디버깅

Kubernetes 통합 개발 지침

이 문서는 GitLab Kubernetes 통합을 개발할 때 다양한 지침을 제공합니다.

개발

아키텍처

일부 Kubernetes 작업, 예를 들어 제한된 프로젝트 네임스페이스 생성은 GitLab Rails 애플리케이션에서 수행됩니다. 이러한 작업은 클라이언트 라이브러리를 사용하여 수행되며 일정한 위험이 있습니다. 이러한 작업은 GitLab Rails 애플리케이션을 실행하는 동일한 사용자로 실행됩니다. 더 많은 정보는 아래의 보안 섹션을 읽어보세요.

일부 Kubernetes 작업, 예를 들어 클러스터 애플리케이션 설치는 쿠버네티스 클러스터 자체의 일회성 pod에서 수행됩니다. 이 설치 pod은 install-<application_name>이라는 이름을 가지며 gitlab-managed-apps 네임스페이스 내에서 생성됩니다.

코드 구성 측면에서, 우리는 일반적으로 lib/gitlab/kubernetes에 Kubernetes 리소스를 표현하는 객체를 추가합니다.

클라이언트 라이브러리

우리는 kubeclient 젬을 사용하여 Kubernetes API 호출을 수행합니다. kubeclient 젬은 단일 클라이언트에서 여러 API 그룹(예: apis/rbac.authorization.k8s.io)을 지원하지 않기 때문에, 우리는 여러분이 이를 달성할 수 있도록 Gitlab::Kubernetes::KubeClient라는 래퍼 클래스를 만들었습니다.

선택된 Kubernetes API 그룹이 지원됩니다. 필요하다면 새로운 API 그룹이나 메서드를 사용해야 하는 경우에는 Gitlab::Kubernetes::KubeClient에 지원을 추가하세요. 내부적으로, 새로운 API 그룹이나 API 그룹 버전은 해당 그룹에 대한 내부 클라이언트를 생성합니다. 새로운 메서드는 관련된 내부 클라이언트로 위임될 수 있습니다.

성능 고려 사항

Kubernetes API에 대한 모든 호출은 백그라운드 프로세스에서 이루어져야 합니다. 웹 요청 내에서 Kubernetes API 호출을 수행하지 마세요. 이는 웹서버를 차단하며, Kubernetes 클러스터 응답 시간이 우리의 제어 범위를 벗어나기 때문에 GitLab에 거부-서비스(DoS) 공격을 일으킬 수 있습니다.

백그라운드 프로세스에서 호출이 일어나도록 하는 가장 쉬운 방법은 해당 작업을 Sidekiq 워커로 위임하는 것입니다.

Kubernetes에 호출을 수행하고 응답을 반환하고 싶을 수 있지만, 백그라운드 워커가 적합하지 않을 수 있습니다. 반응형 캐싱을 사용해 보세요. 예를 들어:

  def calculate_reactive_cache!
    { pods: cluster.platform_kubernetes.kubeclient.get_pods }
  end
  
  def pods
    with_reactive_cache do |data|
      data[:pods]
    end
  end

테스트

우리는 여러분의 테스트에서 Kubernetes API 호출을 가로채는 데 도움이 되는 KubernetesHelpers에 WebMock 스텁을 추가했습니다.

Amazon EKS 통합

이 섹션에서는 GitLab 인스턴스가 EKS 클러스터를 생성할 수 있도록 하는 프로세스를 개요로 설명합니다.

다음 사전 준비 사항이 필요합니다:

고객 AWS 계정. 이 계정에 EKS 클러스터가 생성됩니다. 다음 자원이 있어야 합니다:

• 클러스터를 생성할 권한이 있는 프로비저닝 역할. GitLab AWS 계정을 신뢰하는 신뢰된 엔터티로 나열해야 합니다.
• 클러스터에서 사용할 VPC, 관리 역할, 보안 그룹 및 서브넷.

GitLab AWS 계정. 이 계정에서 프로비저닝 작업을 수행합니다. 다음 자원이 있어야 합니다:

• 고객 계정의 프로비저닝 역할을 가정할 권한이 있는 서비스 계정.
• gitlab.yml의 kubernetes 섹션을 통해 구성된 이 서비스 계정의 자격 증명.

클러스터를 생성하는 프로세스는 다음과 같습니다:

1. :provision_role_arn에서 제공된 :provision_role_external_id를 사용하여 GitLab은 프로바이더 레코드에 일련의 임시 자격 증명을 저장하도록 하는 역할을 가정합니다. 기본적으로 이러한 자격 증명은 한 시간 동안 유효합니다.
2. AWS CloudFormation EKS 템플릿을 기반으로 CloudFormation 스택이 생성됩니다. 이는 EKS 클러스터를 위해 필요한 모든 자원의 생성을 트리거합니다.
3. GitLab은 스택의 상태를 폴링하여 모든 자원이 준비될 때까지 기다립니다. 대부분의 경우 이는 10분에서 15분 사이에 소요됩니다.
4. 스택이 준비되면, GitLab은 클러스터 세부 정보를 저장하고, 이번에는 kubeclient를 통해 클러스터에 연결할 수 있는 또 다른 일련의 임시 자격 증명을 생성합니다. 이러한 자격 증명은 1분 동안 유효합니다.
5. GitLab은 워커 노드를 구성하여 그들이 클러스터에 인증할 수 있도록 하고, 미래 작업을 위해 자체를 위한 서비스 계정을 생성합니다.

6. 더 이상 필요하지 않은 자격 증명이 제거됩니다. 이는 다음 속성을 삭제합니다:

   • access_key_id
   • secret_access_key
   • session_token

보안

서버 측 요청 위조(SSRF) 공격

Kubernetes 클러스터에 대한 URL이 사용자가 제어하기 때문에 서버 측 요청 위조(SSRF) 공격에 쉽게 취약합니다. 클러스터에 더 많은 API 호출을 추가하는 경우 대처 전략을 이해해야 합니다.

대처 전략은 다음과 같습니다:

1. 공격자 컨트롤러 자원으로의 리디렉션을 허용하지 않기: Kubeclient::KubeClient(https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/kubernetes/kube_client.rb#)는 http_max_redirects: 0을 옵션으로 전달하여 리디렉트를 방지하도록 구성할 수 있습니다.

2. 오류 메시지 노출 금지: 공격자가 공격자가 제어하는 요청으로부터 결과를 노출하기 위해 오류를 트리거하는 것을 방지합니다. 예를 들어, 우리는 (또는 저장하지 않음으로써) 원시 오류 메시지를 노출하지 않습니다:

   rescue Kubernetes::HttpError => e
     # bad
     # app.make_errored!("Kubernetes error: #{e.message}")
        
     # good
     app.make_errored!("Kubernetes error: #{e.error_code}")
   

Kubernetes 통합 디버깅

Kubernetes 통합과 관련된 로그는 kubernetes.log에서 확인할 수 있습니다. 로컬 GDK 설치에서는 이러한 로그가 log/kubernetes.log에 존재합니다.

또한, 설치 로그를 따라가서 설치와 관련된 문제를 디버깅할 수 있습니다. 설치/업그레이드가 진행 중인 경우, pod이 생성될 때까지 기다린 후 다음을 실행하여 쓰여지는 대로 pod의 로그를 얻을 수 있습니다:

kubectl logs <pod_name> --follow -n gitlab-managed-apps