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
를 사용하지만 추가 구성 요소를 사용하지 않는다.곡가운이 고객에게 제시한 대체 방안은 작업 부하 신분 추가 구성 요소를 사용하는 것이다.
Google Kubernetes 엔진에서 제공하는 workload identity 플러그인을 사용하면 특정 실행 프로그램과 연결된
Kubernetes Service Account
을 Google 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 likeIstio
,Config Connector
orApplication Manager
ondefault nodepool
because they depend onCompute Engine metadata server
and Workload identity usesGKE metadata server
.
이 때문에 Gitlab 운영자에게 업무 부하에 오류가 발생하지 않도록 전용 GKE 그룹을 제공하는 것을 권장합니다.
워크로드 ID
워크로드 ID 사용
첫 번째 단계는 GKE devops 클러스터를 만들고 구성하는 것입니다.
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
kubectl create namespace dev
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.
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]
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
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
Reference
이 문제에 관하여(Gitlab CI에서 Google 서비스 계정에 액세스했는지 확인), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/stack-labs/securing-access-to-google-service-accounts-from-gitlab-ci-3a9l
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
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]"
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
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
Reference
이 문제에 관하여(Gitlab CI에서 Google 서비스 계정에 액세스했는지 확인), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://dev.to/stack-labs/securing-access-to-google-service-accounts-from-gitlab-ci-3a9l
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
[1]
[2] https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to
Reference
이 문제에 관하여(Gitlab CI에서 Google 서비스 계정에 액세스했는지 확인), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/stack-labs/securing-access-to-google-service-accounts-from-gitlab-ci-3a9l텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)