Cells ネットワーキング

事前学習資料

• HTTP Router
• Topology Service
• ADR 002
• ADR 004

ガイドライン

• GCP における VPC 間通信: 異なる VPC 内のサービス間のあらゆるやり取り。たとえば、Cell が Topology Service と通信する際には Private Service Connect を使用します。これにより、CIDR の重複、VPC ピアリングの制限、VPC 間での一貫性のない DNS 解決、公共インターネット経由の通信を回避できます。
• 認証と認可: 各サービスは、HTTP リクエストを使用した通信に使用される証明書またはトークンの形でアイデンティティを持つ必要があります。そのアイデンティティはリクエストの認可にも使用されます。証明書によるアイデンティティは mTLS として広く知られており、独立したブループリントがあります。
• Cells は公開されていないが、個別にアクセス可能: ユーザーは中央エントリポイントを維持し、レート制限のグローバルカウンターを確保するために、公共インターネット上の gitlab.com ドメインを通じてすべてのリクエストを送信する必要があります。
  • 外部: Cell は外部ホスト名を通じて個別にアクセス可能ですが、これは公開されていません - 顧客は Cell ドメインに直接アクセスできません。
  • 公開: Cell は公共インターネットで利用可能な gitlab.com ドメインを通じてのみ顧客がアクセスできます。

上記のガイドラインに従うと、次のような通信になります。

flowchart LR
    %% Define main entities
    Users((Users))
    GitLabOps(("GitLab Operator Internal Tooling"))

    %% CloudFlare section with components in vertical flow
    subgraph CloudFlare["CloudFlare (GitLab.com)"]
        direction TB
        DoS["DoS"]
        WAF["WAF"]
        RateLimiting["Rate Limiting"]
        Workers["Workers (HTTP Router)"]

        DoS --> WAF --> RateLimiting --> Workers
    end

    %% Google Cloud Platform section
    subgraph GCP["Google Cloud Platform (gitlab-cells.com organization)"]
        direction TB
        subgraph AMPSection["AMP"]
            Jobs["Instrumented Jobs"]
        end

        %% Cells in a horizontal line
        subgraph Cells
            direction LR
            Cell1["cell-0fj2t2v563b55mswz"]
            Cell2["cell-0fj98xaflkwpxmcj"]
            Cell3["cell-0fj98xnabwqagvp"]
        end

        subgraph PSCSection["Private Service Connect"]
            TopologyGRPC["Topology Service (gRPC)"]
        end

        TopologyREST["Topology Service (REST)"]

        %% Connect Jobs to cells more cleanly
        Jobs --> Cells
    end

    %% Add CloudFlare layer for cell communication
    subgraph CellCloudFlare["CloudFlare Layer for Cells"]
        direction TB
        CellDoS["DoS"]
        CellWAF["WAF"]
        CellRateLimiting["Rate Limiting"]

        CellDoS --> CellWAF --> CellRateLimiting
    end

    %% Connect users and operators to CloudFlare
    Users -->|"gitlab.com (Allowed Public)"| CloudFlare
    GitLabOps -->|"gitlab.com (Allowed Public)"| CloudFlare

    %% Direct IDP connection from GitLab Operator to a cell via CloudFlare layer
    GitLabOps -.->|"CF Zero Trust IdP"| CellCloudFlare

    %% Connect workers to CloudFlare layer for cells, then to cells
    Workers -->|"CF ZeroTrust Service Auth"| CellCloudFlare
    CellCloudFlare --> Cells

    %% Connect workers to topology
    Workers -->|"CF ZeroTrust Service Auth"| TopologyREST

    %% Connect cells to Private Service Connect with mTLS
    Cells <-->|"mTLS"| PSCSection

    %% Not allowed connection
    Users -.->|"Not Allowed"| Cell1

    %% No styling for cells

GCP における VPC 間通信

各 Cell は独自の GCP プロジェクトを持ち、その結果独自の VPC を持ちます。 これは、Cell が下流サービスにリクエストを送信する際に、公共インターネットまたは内部ネットワークを経由する必要があることを意味します。 ADR 004 で、内部通信に Private Service Connect を使用することを決定しました。 これは、速度とコストの観点からサービス間のリクエストは内部であるべきであることを意味します。そうしなければ、イングレスとエグレスの料金を支払う必要があります。 Private Service Connect のトラフィックは、中間ホップやプロキシを経由せずに、コンシューマークライアントからプロデューサーバックエンドに直接流れます。 NAT（ネットワークアドレス変換）はコンシューマーとプロデューサーの VM をホストする物理ホストマシン上で直接実行されるため、レイテンシが低減し、帯域幅容量が向上します。

Private Service Connect は GCP ホストサービス間の通信にのみ使用されます。HTTP Router は GCP でホストされていないため、HTTP Router と Topology Service の間では使用できません。

Private Service Connect には 2 つのエンティティがあります: Consumer と Producer です。例えば、Cell（Consumer）が Topology Service（Producer）にリクエストを送信する場合です。

Consumer が Producer にアクセスする方法には Endpoint と Backend の 2 つがあります。Private Service Connect Backend は Private Service Connect ネットワークエンドポイントグループ（NEG）バックエンドで設定されたロードバランサーを使用するため、Backend を使用します。 コンシューマー管理のロードバランサーを通じて API とサービスにアクセスすることには、いくつかのメリットがあります:

• ロードバランサーはセキュリティポリシー（Google Cloud Armor ポリシーや SSL ポリシーなど）またはルーティングポリシー（Google Cloud URL マップなど）が適用される集中型ポリシー適用ポイントとして機能できます。
• パブリッシュされたサービスが提供しない可能性のある集中型メトリクスとロギングを提供します。
• コンシューマーがルーティングとフェイルオーバーを制御できます。
• Geo のフェイルオーバー用に Cell が複数のリージョンで動作しており、Topology Service が 2 つのリージョンで動作しているため、すべてのロードバランサーはデフォルトでマルチリージョンである必要があります。

source

認証と認可

mTLS と Cloudflare Zero Trust を組み合わせて活用します。 各 Cell は、認証の手段として Topology Service に接続するために使用される証明書の形でアイデンティティを持つ必要があります。 認可の実装は Topology Service に委ねられており、証明書に含まれるアイデンティティを使用します。 例えば、Cell は認証のために mTLS を使用して Topology Service に接続し、その後 Topology Service はそのアイデンティティを使用してリクエストを実行できるかどうかを認可します。

認証プロトコルと接続マトリクス

Cells は公開されていないが、個別にアクセス可能

すべての公開トラフィックは現在と同様に gitlab.com ドメインを経由して流れます。 これにより、可観測性、監査追跡、前方/後方互換性のための単一のエントリポイントが提供され、Web Application Firewall とレート制限を設定・管理する集中型の場所が確保されます。

各 Cell はテナントモデル内で managed_domain として知られる専用ドメインを持ち続けます。これは Cloudflare に登録されます。 この理由は 認証と認可 に基づいており、各ワークロードが独自のアイデンティティを持ち、Topology Service と HTTP Router が Cell の識別子を持つためです。 Cell は、プログラム的にクライアントによってだけでなく、HTTP Router と Topology Service を迂回して、Rails アプリケーションのデバッグなど運用上の理由で直接接続するヒューマンオペレーターにも直接アクセス可能である必要があります。

これは、Cell には 2 種類のクライアント（ヒューマンクライアントと HTTP Router や Instrumentor などの他のサービス）があることを意味します。両方とも Cloudflare Zero Trust を使用した同じコアテクノロジーで解決されます。

ヒューマンオペレーター

Cloudflare Zero Trust では、Okta などの Identity Provider を設定できます。これにより、ブラウザで managed_domain にアクセスすると、Cell に続くために Okta にログインすることが求められます。

Cloudflare ZeroTrust のアプリケーションにアクセスポリシーを設定して、特定の Okta グループに属するオペレーターのみにアクセスを制限できます。

これは Cloudflare Zero Trust PoC によって検証されています。

サービス

HTTP Router から Cell および Topology Service へのセキュアな通信には、Cloudflare Zero Trust の Service Token Auth を活用できます。

サービス認証トークンは Worker シークレットとしてアップロードでき、Cell へのリクエストをプロキシする際にヘッダーとして追加できます。

CloudFlare Zero Trust PoC の一環としてこれがどのように機能するかを検証しました。

ページのソースコードを見る - ページの編集 - please contribute.