Gitlab CI에서 Google 서비스 계정에 액세스했는지 확인


블레키르 기욤

60만 유로는 한 회사의 최근 서비스 계좌 키 파일 유출의 영향이다.조심스럽게 사용하고 다른 옵션이 없을 때만 사용하세요.ADC, 시뮬레이션, 작업 부하 표지, 작업 부하 연합...너는 선택이 많아!
2021년 8월 27일 오전 7:26
Gitlab CI 구성에서 매일 몇 개의 서비스 계정 키가 변수로 저장됩니까?Google Service Accounts Key 파일이 Gitlab에 저장될 때 우리는 클라우드 인프라 시설 외에 증거를 저장하는 모든 안전 문제에 직면하게 될 것이다. 방문, 권한 수여, 키 교체, 나이, 소각, 위치 등이다.
Gitlab CI에 GCP 자격 증명을 저장하는 개발자의 일반적인 이유는 다음과 같습니다.
  • 그들이 사용한다shared runners.
  • 그들은 specific runners 집단에 배치된 Google Kubernetes Engine를 사용하지만 추가 구성 요소를 사용하지 않는다.
  • Gitlab CI에서 GSA 키를 계속 사용할 수 있고,Vault와Forseti 등 외부 도구로 키를 보호할 수 있지만, 다른 관리 도구가 추가됩니다.
    곡가운이 고객에게 제시한 대체 방안은 작업 부하 신분 추가 구성 요소를 사용하는 것이다.
    Google Kubernetes 엔진에서 제공하는 workload identity 플러그인을 사용하면 특정 실행 프로그램과 연결된 Kubernetes Service AccountGoogle service account 에 연결할 수 있습니다.

    Note: At the time of writing this post, when you enable Workload identity you will not be able to use some GKE add-ons like Istio, Config Connector or Application Manager on default nodepool because they depend on Compute Engine metadata server and Workload identity uses GKE metadata server.


    이 때문에 Gitlab 운영자에게 업무 부하에 오류가 발생하지 않도록 전용 GKE 그룹을 제공하는 것을 권장합니다.

    워크로드 ID 워크로드 ID 사용


    첫 번째 단계는 GKE devops 클러스터를 만들고 구성하는 것입니다.
  • GKE 클러스터를 먼저 만들었습니다[1].
  • gcloud projects create mycompany-core-devops
    gcloud config set project mycompany-core-devops
    gcloud services enable containerregistry.googleapis.com
    gcloud container clusters create devops \
      --workload-pool=mycompany-core-devops.svc.id.goog
    
    runner 작업에 대한 nodepool을 만듭니다.
    gcloud container node-pools create gitlab-runner-jobs-dev \
      --cluster=devops \  
      --node-taints=gitlab-runner-jobs-dev-reserved=true:NoSchedule \  
      --node-labels=nodepool=dev \  
      --min-nodes=0 --max-nodes=3
    
  • 구성kubectl과 클러스터 통신:
  • gcloud container clusters get-credentials devops
    
  • Kubernetes 서비스 계정에 사용할 이름 공간을 만듭니다.
  • kubectl create namespace dev
    
  • 특정 주자를 위한 Kubernetes 서비스 계정을 만듭니다.
  • kubectl create serviceaccount --namespace dev app-deployer
    
  • 특정 주자를 위한 구글 서비스 계정 만들기
  • gcloud projects create mycompany-core-security
    gcloud config set project mycompany-core-security
    gcloud iam service-accounts create app-dev-deployer
    

    Note: For easier visibility and auditing, I recommend to centrally create service accounts in dedicated projects.

  • Kubernetes 서비스 계정은 IAM 정책 바인딩을 통해 Google 서비스 계정을 시뮬레이션할 수 있습니다.이러한 바인딩을 통해 Kubernetes 서비스 계정을 Google 서비스 계정으로 사용할 수 있습니다.
  • gcloud iam service-accounts add-iam-policy-binding \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:mycompany-core-devops.svc.id.goog[dev/app-deployer]" \
      [email protected]
    
  • Google 서비스 계정의 이메일 주소를 사용하여 iam.gke.io/gcp-service-account=app-dev-deployer@mycompany-core-security.iam.gserviceaccount.com 설명을 Kubernetes 서비스 계정에 추가합니다.
  • kubectl annotate serviceaccount \
      --namespace dev \
      app-deployer \
      iam.gke.io/gcp-service-account=[email protected]
    

    Gitlab runner에 KSA 할당


    다음 단계는 KSA를 Gitlab runner에 할당하는 것입니다.
  • 헬멧 설치부터:
  • curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
    chmod 700 get_helm.sh
    ./get_helm.sh
    
  • Gitlab Helm 패키지 추가:
  • helm repo add gitlab https://charts.gitlab.io
    
  • 구성 실행:
  • 파일 생성values.yaml:
    imagePullPolicy: IfNotPresent
    gitlabUrl: https://gitlab.com/
    runnerRegistrationToken: "<>"
    unregisterRunners: true
    terminationGracePeriodSeconds: 3600
    concurrent: 10
    checkInterval: 30
    rbac:
      create: true
    metrics:
      enabled: true
    runners:
      image: ubuntu:18.04
      locked: true
      pollTimeout: 360
      protected: true
      serviceAccountName: app-deployer
      privileged: false
      namespace: dev
      builds:
        cpuRequests: 100m
        memoryRequests: 128Mi
      services:
        cpuRequests: 100m
        memoryRequests: 128Mi
      helpers:
        cpuRequests: 100m
        memoryRequests: 128Mi
      tags: "k8s-dev-runner"
      nodeSelector: 
        nodepool: dev
      nodeTolerations:
        - key: "gitlab-runner-jobs-dev-reserved"
          operator: "Equal"
          value: "true"
          effect: "NoSchedule"
    

    You can find the description of each attribute in the Gitlab runner charts repository [2]

  • Project -> Settings -> CI/CD -> Runners 부분Setup a specific Runner manually에서 Gitlab 등록 영패를 받았습니다.
  • 휠 장착:
  • helm install -n dev app-dev-runner -f values.yaml gitlab/gitlab-runner
    

    Gitlab CI에서 특정 실행 프로그램 사용


    Gitlab CI에서 첫 번째 파이프라인을 실행하기 전에 새로운 업무 프로젝트를 만들고 Kubernetes cluster 관리자 권한을 GSA에 추가합니다.
    gcloud projects create mycompany-business-dev
    gcloud config set project mycompany-business-dev
    gcloud projects add-iam-policy-binding mycompany-business-dev \
      --role roles/container.clusterAdmin \
      --member "serviceAccount:[email protected]"
    
    현재 우리는 우리의 파이프.gitlab-ci.yml를 운행할 수 있다.
    stages:
      - dev
    
    infra:
      stage: dev
      image: 
        name: google/cloud-sdk
      script: 
        - gcloud config set project mycompany-business-dev
        - gcloud services enable containerregistry.googleapis.com
        - gcloud container clusters create business
      tags:
        - k8s-dev-runner
    
    이 작업은 mycompany-business-dev 프로젝트에 GKE 클러스터를 만듭니다.prod 환경에 대해 우리는 같은 절차를 따를 수 있다.

    한층 더


    GSA가 업무 집단의 특정 이름 공간에서만 Kubernetes 목록을 만들 수 있도록 할 수 있습니다.
    파일 생성rbac-dev.yaml
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: app
      name: devops-app
    rules:
    - apiGroups: [""]
      resources: ["pods", "pods/exec", "secrets"]
      verbs: ["get", "list", "watch", "create", "patch", "delete"]
    ---
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: devops-app-binding
      namespace: app
    subjects:
    - kind: User
      name: [email protected]
    roleRef:
      kind: Role
      name: devops-app
      apiGroup: rbac.authorization.k8s.io
    
    rbac 만들기
    gcloud config set project mycompany-business-dev
    gcloud container clusters get-credentials business
    kubectl create namespace app
    kubectl apply -f rbac-dev.yaml
    
    Kubernetes 자원을 만들 수 있는 권한을 지정하는 것을 잊지 마십시오.
    gcloud projects add-iam-policy-binding mycompany-business-dev \
      --role roles/container.developer \
      --member "serviceAccount:[email protected]"
    
    비즈니스 클러스터에 새pod를 만듭니다.
    manifests:
      stage: dev
      image: 
        name: google/cloud-sdk
      script: 
        - gcloud config set project mycompany-business-dev
        - gcloud container clusters get-credentials business
        - kubectl run nginx --image=nginx -n app
      tags:
        - k8s-dev-runner
    
    기본 이름 공간에서nginx pod를 만들려고 시도하면 실패하고 권한이 부여되지 않은 접근 오류가 발생합니다.

    결론


    본고에서 우리는 GSA를 특정한 GCP 프로젝트에 집중하고 최종적으로 하나의 업무 프로젝트에 GCP와 Kubernetes 자원을 배치하는 devops 그룹을 만들었다.
    이러한 메커니즘은 GSA 리소스의 완벽한 보안을 보장합니다.크로스 작업을 쉽게 만들 수 있습니다. 저녁에 GSA를 사용하지 않고, 일요일 아침에 다시 사용할 수 있습니다.
    질문이나 피드백이 있으면 언제든지 댓글을 달아주세요.
    그렇지 않으면 Gitlab CI 변수에서 GSA 키를 제거하고 워크로드 ID를 사용하는 GKE에서 특정 실행 프로그램을 사용하도록 설득했으면 합니다.
    겸사겸사 한마디 하자면 또래와 나누는 것을 주저하지 마라😊
    읽어주셔서 감사합니다!

    문서


    [1]
    [2] https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to

    좋은 웹페이지 즐겨찾기