CircleCI Server v3.x クラスタのハードニング

CircleCI Server システムでは主に、Kubernetes ノード、Nomad クライアント、外部 VM という 3 種類のコンピューティングインスタンスを実行します。

これらのインスタンスは、CIDR ブロックの異なるサブネットに分けてデプロイすることを強くお勧めします。 そうすることで、システムのコンポーネント間を流れるトラフィックの制御やそれぞれの分離がしやすくなります。

通例どおり、リソースはできる限り非公開にすることが原則です。 CircleCI Server システムへのユーザーアクセスが VPN 経由であり、かつ NAT ゲートウェイが適切に設定されていれば、パブリック IP アドレスの割り当ては必要ありません。 そうでない場合は、 CircleCI Server Traefik ロードバランサー用にパブリックサブネットを少なくとも 1 つ用意する必要があります。

ただし、この場合には、パブリックサブネットに Nomad クライアントと VM を配置して、ジョブにユーザーが SSH 接続できるようにするとともに、ネットワークルールでアクセススコープを設定することもお勧めします。

現時点では、GCP はカスタムのサブネット化には対応していません。 カスタムのサブネット化は、今後の更新/リリースで使用可能になる予定です。

このセクションでは、CircleCI Server システムの稼働に必要な最小要件について説明します。 ワークロードによっては、Nomad クライアントと VM の送信にルールを追加する必要があります。 クラウドプロバイダーごとに名称は異なります。 そのため、ファイアウォール ルールやセキュリティグループなどを使用した実装が必要になる可能性があります。

表中の "外部" は、特に断りがない限り、すべての外部 IPv4 アドレスを意味します。 ただし、外部トラフィックすべてにプロキシを使用している場合など、お使いの環境によっては、より具体的に指定することができます。

なお、ここでは、Nomad、VM サービス、出力プロセッサそれぞれのロードバランサーは、すべて内部ロードバランサーにすることを前提としています。 （内部ロード バランサーがデフォルトです。）

また、下記のルールは、特別な記載のない限り、TCP 接続に対してステートフルで設定するものとします。 ステートレスルールを使用する場合には、下表の各項目に該当する送受信ルールをそれぞれ作成してください。

お使いの環境によっては、ロード バランサーが透過的である (ネットワーク トポロジの個別のレイヤーとしては扱われない) ことがあります。 この場合には、ロード バランサーの背後にあるネットワーク トラフィックの送信先またはソースに対して、本セクションのルールを直接適用してください。 CircleCI Server システムで使用している負荷分散の種類に応じたネットワーク セキュリティ ルールの適切な適用方法については、ご利用のクラウド プロバイダーのドキュメントをご覧ください。

以下のルールは、ロードバランサーを除くすべてのコンピューティングインスタンスに適用されます。

Nomad クライアント同士は、通信する必要はありません。 Nomad クライアント インスタンス 間のトラフィックを完全にブロックできます。

Nomad クライアントと同じく、外部 VM 同士も通信する必要はありません。