Tadashi Nemoto
Published on

セルフホスト(self-managed)版 GitLab と CircleCI クラウドを IP アドレスベースでセキュアに接続する方法

Authors

セルフホスト(self-managed)版 GitLab と CircleCI クラウドを IP アドレスベースでセキュアに接続する方法

この記事では、CircleCI が提供する IP アドレス範囲機能を利用して、セルフホスト(self-managed)版 GitLab と CircleCI クラウドを IP アドレスベースでセキュアに接続する方法について紹介します。

CircleCI クラウドのセルフホスト(self-managed)版 GitLab サポート

CircleCI クラウドはこの度、セルフホスト(self-managed)版 GitLab のサポートをリリースしました。

CircleCI に GitLab が対応 | CircleCI

セルフホスト(self-managed)版 GitLab では、GitLab CI を自前でホストして CI/CD パイプラインを作ることもできますが、様々な課題が出てきます。

  • コンピューティングリソースの制限によって、ビルドスピード・並列数に制限が出てしまう

  • iOS アプリケーションのビルド・テストに必要な macOS を利用するのが困難

  • デバッグ・可視化・セキュリティ・テスト分割など、開発者が求める CI/CD 機能に不足が出てしまう

今回の CircleCI のサポートによって、セルフホスト(self-managed)版 GitLab を利用している開発者でも高性能な CI/CD 環境を利用することができます。

CircleCIとGitLabCIの比較

しかし、セルフホスト(self-managed)版 GitLab と CircleCI クラウドを接続するためには以下の制約があります。

self-managed インスタンスはパブリックインターネットからアクセス可能である必要があります。ファイアウォールの内側に配置している場合は使用できません。

しかしながら、特に企業でセルフホスト(self-managed)版 GitLab を利用している場合には、やみくもにパプリックインターネットからアクセスできる状況にしたくないと思われます。

今回はこの問題を解決するために、CircleCI が提供する IP アドレス範囲機能を利用して、セルフホスト(self-managed)版 GitLab と CircleCI クラウドを IP アドレスベースでセキュアに接続する方法について紹介します。

CircleCI の IP アドレス範囲機能

通常 SaaS 型の CI/CD ツールでは、IP アドレス範囲が固定化されておらず、ファイアウォールが設定されている環境と接続するのが困難な場合があります。

CircleCI が提供する IP アドレス範囲機能を利用することによって、CircleCI で使用される 30 個の IP アドレス (一覧はこちら) のいずれかに、送信トラフィックがルーティングされるようになります。

これによって、IP アドレスベースのファイアウォールで環境を守りながら、CircleCI との通信だけを許可することができます。

IP アドレスの範囲機能で、より安心できるセキュリティを確保 | CircleCI

今回はこの IP アドレス範囲機能を利用して、以下の図のような形でセルフホスト(self-managed)版 GitLab と接続をします。

セルフホスト(self-managed)版 GitLab × IP アドレス範囲アーキテクチャー

事前準備

  • セルフホスト(self-managed)版 GitLab

    • Community Editon, Enterprise Edition どちらでも可能です。
    • 今回は GitLab Helm Chart を利用してインストールしています。

  • CircleCI クラウド

セルフホスト(self-managed)版 GitLab で CircleCI の IP アドレスを許可する

まずはセルフホスト(self-managed)版 GitLab において、以下の IP アドレスを許可するように設定します。

今回は GitLab Helm Chart を利用してインストールしているため、同時にインストールされている NGINX Ingress Controller の loadBalancerSourceRanges を使って IP アドレスを許可します。

nginx-ingress:
  controller:
    service:
      loadBalancerSourceRanges: [
        # IP Ranges
        3.228.39.90/32
        18.213.67.41/32,
        34.194.94.201/32,
        34.194.144.202/32,
        34.197.6.234/32,
        ...

        # Core
        18.214.70.5/32,
        52.20.166.242/32,
        18.214.156.84/32,
        54.236.156.101/32,
        ...

helm upgrade --install gitlab gitlab/gitlab --values gitlab_config.yaml

プロジェクトのセットアップ

次に、IP アドレスを許可したセルフホスト(self-managed)版 GitLab と CircleCI を接続した上で、プロジェクトのセットアップを行います。

以下のドキュメントにある「GITLAB SELF-MANAGED」に従ってセットアップを行なってください。

GitLab との連携 - CircleCI

IP アドレス範囲機能を有効にしたパイプラインを作成する

プロジェクトのセットアップが完了したら、IP アドレス範囲機能を有効にしたパイプラインを作成していきます。

すべてのジョブに対して IP アドレス範囲を有効にするフラグ circleci_ip_ranges: true を追加してください。

jobs:
  unit_test:
    circleci_ip_ranges: true # IP アドレス範囲機能を有効
    docker:
      - image: cimg/node:18.14.0
    steps:
      - checkout
      - node/install-packages
      - run: npm run test:ci

設定ファイルが正しく反映されると、セルフホスト(self-managed)版 GitLab から CircleCI にパイプラインがトリガーされます。

CircleCI の UI だけではなく、GitLab の Merge Request などの UI からステータスを確認することができます。

GitLabのステータス

Docker イメージのビルド・プッシュを行いたい場合(kaniko)

現在 IP アドレス範囲機能は Docker Executor のみの対応になっています。

そのため、通常は以下の理由によって Docker イメージのビルド・プッシュを行うことはできません。

  • Machine Executor(Linux VM など)を利用することができない

  • Docker Executor 内では DinD(Docker in Docker) になってしまう

しかし、Docker Executor 内であっても kaniko を利用することによって DinD(Docker in Docker) を回避することができます。

これによって、IP アドレス範囲機能を有効にした状態で、Docker イメージのビルド・各レポジトリ(Docker Hub, Amazon ECR, Azure Container Registry)へのプッシュを行うことができます。

以下は IP アドレス範囲機能を有効にした上で、kaniko を利用して Docker イメージのビルド・DockerHub へのプッシュを行なっているジョブの例です。

kaniko-build-push-docker-hub:
  circleci_ip_ranges: true # IP アドレス範囲機能を有効
  environment:
    DOCKER_REGISTRY: docker.io
  docker:
    - image: gcr.io/kaniko-project/executor:debug
      entrypoint: ''
  steps:
    - checkout
    - run:
        name: add Docker Hub credentials
        command: |
          mkdir -p /kaniko/.docker
          ./config.sh
          mv config.json /kaniko/.docker
    - run:
        name: Build and Push image
        command: |
          /kaniko/executor \
              --context "$(pwd)" \
              --dockerfile "$(pwd)/Dockerfile" \
              --destination "${DOCKER_REGISTRY}/tadashi0713/gitlab-kaniko:${CIRCLE_SHA1}"

詳細は以下のドキュメントを参考にしてください。

How-to: build and push Docker images with Kaniko - Tips, Tricks and Hacks - CircleCI Discuss

macOS を利用したい場合

CircleCI クラウドでは macOS VM をクラウドネイティブに利用することができ、かつIP アドレス範囲が公開されています。

これらの IP アドレス範囲を、先ほどと同じくセルフホスト(self-managed)版 GitLab で許可してあげることによって、macOS VM に接続することができます。

nginx-ingress:
  controller:
    service:
      loadBalancerSourceRanges: [
        # macOS
        162.252.208.0/24,
        162.252.209.0/24,
        192.206.63.0/24,
        162.221.90.0/24,
        38.39.177.0/24,
        ...
  • macOS のビルドは記載されてる IP アドレスに自動的に制限されます。 つまり macOS のビルドでは、circleci_ip_ranges: true を明示的に設定する必要がありません。

CircleCI では M1 Mac も提供されており、iOS ビルドなどのパフォーマンスを大幅に向上させることができます。

CI/CD パイプラインが M1 に対応し Apple Silicon でのビルドが可能に

CircleCI M1 Mac パフォーマンス比較

注意点

  • 現在 IP アドレス範囲機能は、Performance プランおよび Scale プランで利用できます。

  • 現在、IP アドレス範囲機能を使用できるのは、Docker Executor (remote_docker を除く) のみです。

  • IP アドレスの範囲機能の利用には、この機能を有効にしたジョブで使用されるデータ 1GB につき、450 クレジットがかかります。

Discuss on Twitter • View on GitHub