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 同士も通信する必要はありません。