からGoogleサービスアカウントへのアクセスを確保する

17138 ワード
gitlab devops security googlecloud テキストリンク

ブラキェレギョーム

600 000は、それが会社の最近のサービスアカウントキーファイル漏れの影響です.注意して使用し、他のオプションが使用できない場合に限ります.AMC、偽装、ワークロードアイデンティティ、ワークロード連盟、...あなたは選択肢がたくさんある!
午前7時26分- 2021年8月27日
どのように多くのサービスアカウントのキーは、GitLab CIの設定の変数として一日に格納されますか?
時Google Service Accounts Key GITLABに保存され、クラウドのインフラストラクチャの外に資格情報を格納するすべてのセキュリティ上の問題に直面する:アクセス、認証、キーの回転、年齢、破壊、場所など.
開発者がgtlab ciでgcpの資格情報を保存するには2つの一般的な理由があります.
  • 利用するshared runners .
  • 利用するspecific runners Aで配備されるGoogle Kubernetes Engine クラスタが使用しないWorkload Identity アドオン.
    • GITLAB CIのGSAキーを使用してVaultやForsetiのような外部ツールを使用してキーを確保し続けることができますが、これは管理するための追加のツールを追加します.
    Googleクラウドが顧客に提案する選択肢は、ワークロードアイデンティティアドオンを有効にすることです.
    Google Kubernetesエンジンで提供されるワークロードIDアドオンは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 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の操作


    最初のステップは、GKE devopsクラスタの作成と設定です.
  • 私たちはGKEクラスタを作成することから始めます.
    • 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
    ランナー仕事のために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
  • 特定のランナーのためのGoogleサービスアカウントを作成します
    • 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サービスアカウントを2つの間で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]
  • 追加するiam.gke.io/gcp-service-account=app-dev-deployer@mycompany-core-security.iam.gserviceaccount.com Kubernetesサービスアカウントへの注釈、Googleサービスアカウントのメールアドレスを使用します.
    • kubectl annotate serviceaccount \
  --namespace dev \
  app-deployer \
  iam.gke.io/gcp-service-account=[email protected]

    GITLABランナーにKSAを割り当てる


    次のステップは、我々のgitlabランナーにKSAを割り当てることです.
  • ヘルムをインストールする
    • 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 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]

  • からのGitlab登録トークンを得てくださいProject -> Settings -> CI/CD -> Runners にSetup a specific Runner manually セクション.
  • ランナーをインストール
    • helm install -n dev app-dev-runner -f values.yaml gitlab/gitlab-runner

    Gitlab CIで特定のランナーを使用する


    Gitlab CIで最初のパイプラインを実行する前に、新しいビジネスプロジェクトを作成し、Kerbernetesクラスタ管理者の許可を以前に作成した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 プロジェクト我々は、同じ手順に従うことができます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]"
    ビジネスポッドに新しいポッドを作りましょう
    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
    NGNXX PODをデフォルトの名前空間に作成しようとすると、不正アクセスのエラーが発生します.

    結論


    このポストでは、我々はDEVOPSクラスタを作成しました、我々は特定のGCPプロジェクトで我々のGSAを集中させました、そして、我々はビジネスプロジェクトで我々のGCPとKubernetes資源を配備しました.
    この機構は、GSAリソースのエンドツーエンドのセキュリティを保証します.あなたは簡単に夕方にGSAを無効にし、作業日の朝にそれらを再有効にするcronジョブを作成することができます.
    ご質問やご意見がある場合は、コメントを残して自由に感じてください.
    さもなければ、GITLAB CI変数からGSAキーを削除して、ワークロードIDを有効にしてGKEで特定のランナーを使用するように確信していることを願っています.
    ところで、仲間と共有することを躊躇しないでください😊
    読書ありがとう!

    ドキュメント


    〔1〕https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to
    〔2〕https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/main/values.yaml
    etcdクラスタの導入
    Lv.数字の表示