インフラ部門のプロジェクト

インフラ部門は GitLab プロジェクトを使用して、GitLab.com および GitLab Inc. のサポートサービスを運用しています。これはGitLab エンジニアリングプロジェクトに加えてのものです。

このページは project の明確な定義を提供することを目的としています:

1. 種類
2. データ分類
3. 正規およびミラーの場所
4. オーナーシップとアクセス

種類

データ分類

正規の場所

インフラ部門のワークフローは、製品をドッグフーディングするためだけでなく、一般的なワークフローをサポートするためにも使用される多数の GitLab インスタンスを通じて分割されています。一般的に、インフラ部門が日常的なワークフローをサポートするために使用する 2 つのインスタンスがあります:

1. GitLab.com
2. ops.gitlab.net

インフラ部門は作業の整理と計画に GitLab.com を使用しています。

GitLab.com を運用するために ops.gitlab.net を使用しています。必要なすべての依存関係をミラーリングするためだけでなく、ミッションクリティカルなプロジェクトを実行するためにも ops.gitlab.net を使用しています。

正規の場所は以下の基準に基づいて選択されます:

オーナーシップとアクセス

プロジェクトのオーナーシップとアクセスは、データ分類とプロジェクトの目的、および正規のソースと密接に関連しています。

プロジェクトのオーナーシップは、可能な場合、他の人のコラボレーションを排除するべきではありません。代わりに、プロジェクトのワークフローを尊重しながら、できる限り広いアクセスを提供する必要があります。

以下の表は説明的な例を示しています。

例えば、ops.gitlab.net のワークロードとして分類された制限付きプロジェクトは、日常業務のためにアクセスを必要とする部門全員にアクセスが付与されます。ただし、この同じプロジェクトが GitLab.com に安全にミラーリングできる機密コードを含まない場合、ミラーされた場所でより広いコミュニティに完全にアクセス可能にできます。

この説明に当てはまるプロジェクトの具体的な例は deployer プロジェクトです。ランタイムには、このプロジェクトのパイプラインが本番システムに接続するため、このプロジェクトには機密情報が含まれます。これが、プロジェクトが ops.gitlab.net にあり、インフラ部門のみがアクセスできる理由です。しかし GitLab.com のミラーは、このプロジェクトのスクリプトが機密情報を含まないため、誰でも完全にパブリックにアクセスできます。

透明性の価値を尊重しながらも、価値の階層を尊重して、プロジェクトをケースバイケースでレビューします。

ワークフロー

GitLab プロジェクトには、作業をより簡単に達成できるさまざまな機能があります。本質的に、私たちのワークフローは通常以下で構成されています:

1. プロジェクト管理 - Issue、エピック、Issue ボード
2. コードコラボレーション - ピアレビューを伴うマージリクエスト
3. テストとデプロイメント - CI および CD パイプライン

GitLab は、さまざまなレベルの複雑さで、プロジェクトが 1 つの場所にある場合と同様の方法でワークフローに対処するために、これらのワークフローを異なる場所に分離することができます。ランタイムに機密情報を処理するがコードはパブリックにアクセス可能なプロジェクトの例として、ワークフローをサポートするために活用できる GitLab 機能を以下の表に示します:

これは、ops.gitlab.net に正規リポジトリを持ち、ランタイムに最小権限アクセスを持つプロジェクトが、gitlab.com でパブリックにできることを意味します。ソースコードは gitlab.com にミラーリングでき、そこで Issue を提起して議論できます。CI を必要とし、デプロイを行う MR を通じた開発は ops.gitlab.net のみで有効にします。 この例では、ワークフローをサポートするコードを共有しながら、透明性を確保しつつも、効率的かつ安全に結果を提供できることを示しています。

正規の場所でのプロジェクト整理

ops.gitlab.net

以下の図は、インフラ部門のプロジェクトが運用インスタンスでどのように整理されているかを示しています。

トップレベルグループは Infrastructure という名前で、インフラ部門が日常業務に使用するすべてのプロジェクトを含んでいます。そのグループの名前が gl-infra でない理由は、その名前の既存グループがすでに存在しており、名前と場所から GitLab に関連することが明らかだからです。 このグループへのアクセスはグループオーナーとインスタンス管理者にのみ付与されます。サブグループとそのサブグループ内のプロジェクトへのアクセスは、特定のチームグループに付与されます。個人ユーザーアカウントはチームグループ外のプロジェクト/サブグループに追加されません。

graph LR
A[Infrastructure] --> B[Workloads]
A --> J[Lib]
A --> M[Tools]
A --> P[Sandbox]
A --> S[Team]

subgraph Mission critical
B --> C[kubernetes]
B --> D[terraform]
B --> F[chef-repo]
B --> G[deployer]

subgraph k8s
  C --> H[monitoring]
  C --> I[gitlab.com]
end
end

subgraph Libraries
  J --> K[modules]
  J --> L[cookbooks]
end

subgraph Tooling
  M --> N[Certificate uploader]
  M --> O[slackline]
end

subgraph Testground
  P --> R[testing-poc]
end

subgraph Team management
  S --> T[delivery]
  S --> U[observability]
end

GitLab.com

GitLab.com に現在あるプロジェクトは複数のグループ/サブグループと個別プロジェクトに分散しています。このページが導入された時点では、ops.gitlab.net の整理に焦点を当てており、その後 GitLab.com のプロジェクト再整理が続く予定でした。

適切なプロジェクトワークフローの選択

プロジェクトに適したワークフローを決定するには多くの変数があります。最も簡単なアプローチはすべてのプロジェクトに単一のワークフローを持つことですが、このアプローチは透明性の価値に反します。過去にはすべてをパブリックにするアプローチを取ったこともありますが、それは GitLab.com プラットフォームに影響するインシデント中に迅速に結果を提供することを妨げ、過度なパブリック情報が不必要なセキュリティリスクをもたらすため困難でした。

このセクションでは、一般的なワークフローの例とプロジェクトを分類する決定へのアプローチを提供します。

機密情報を持つミッションクリティカルプロジェクト

このタイプのプロジェクトの例は Terraform 環境です。このプロジェクトにはインスタンスタイプ、サービスアカウント名など、インフラの詳細がすべて含まれています。これらの詳細はそれ自体では問題ではなく、必ずしもプライベートである必要はありませんが、悪意のある攻撃者が攻撃ベクターを作成するのを無限に容易にします。さらに、偶発的な変更はプラットフォームに即座に影響を与える可能性があります。

これらのタイプのプロジェクトは以下の表に基づいて設定する必要があります:

このタイプの整理により、会社全体がソースコードにアクセスして Issue でフィードバックを提供できます。MR へのリンクは、正規リポジトリで行われている作業の DRI が手動で追加する必要があります。ランタイムには、このタイプのプロジェクトは日常業務のためにアクセスを必要とする人々にのみアクセス可能です。

重要 プロジェクトがこのように分類されている場合、プロジェクトの README ファイルには「なぜこのプロジェクトへのアクセスが制限されているのか?」という質問に答えるセクションが必要です。いつでも、この分類に合うプロジェクトはほんの数個であるべきです。

ランタイムに機密性を持つミッションクリティカルプロジェクト

このタイプのプロジェクトの例は Kubernetes gitlab.com プロジェクトです。このプロジェクトには機密と見なせる情報が含まれているコードが含まれていますが、情報の大部分はパブリックにできます。ただし、ランタイムにこのプロジェクトは本番の機密ワークフローに接続し、管理者レベルのトークンと対話する可能性があります。MR は技術的には GitLab.com で作業できますが、パイプラインは別のインスタンスで実行されるため、ミスがプラットフォームのダウンタイムを引き起こす可能性があります。この理由から、プロジェクトは以下のように設定する必要があります:

ミッションクリティカルなワークロードをサポートするプロジェクト

このタイプのプロジェクトの例は omnibus-gitlab クックブックです。このプロジェクトはインフラ全体に omnibus-gitlab パッケージをインストールするため、ミッションクリティカルなワークフローをサポートしています。ランタイムには、このプロジェクトが機密情報と連携する可能性が高いです。 ただし、このプロジェクトの機密性は、使用できないことが運用緊急時に不便を引き起こすことにあるだけで、プロジェクトのミラーを常に利用可能にすることで解決できます。より広いコミュニティがこのプロジェクトから恩恵を受け、自分たちのインストールにコードを活用できるため修正を貢献する可能性があります。プロジェクトは以下のように設定できます:

この分類基準を満たすプロジェクトは、パブリックな Terraform モジュール、Ansible スクリプトなどである可能性が高いです。

メンテナンスツールと自動化プロジェクト

このタイプのプロジェクトの例は証明書管理スクリプトセットです。このタイプのプロジェクトは日常機能を自動化し、動作するために機密リソースを必要とする可能性があります。ただし、プロジェクト自体の機密性はそれだけであり、作業を慎重に考慮することで問題を回避できます。より広いコミュニティはプロジェクトを見ることから直接の恩恵を受けないかもしれませんが、プロジェクトをプライベートにしておくメリットもありません。これらのタイプのプロジェクトは以下のように設定できます:

進行中の作業プロジェクト

サンドボックスグループにあるプロジェクトは、上記で参照した他のワークフローのいずれかに卒業する可能性があるプロジェクトです。概念実証、一度限りのマイグレーションのクイックスクリプト、または一度限りのメンテナンスをサポートするスクリプトはすべてこのグループに属します。

プロジェクトが定期的に再利用される場合は、使用される前に他のグループのいずれかに移行する必要があります。これはまた、プロジェクトが部門全体によって維持されることを示します。移行後は、これらのプロジェクトはそのグループの分類に従って扱われます。それまでは、これらのプロジェクトは GitLab.com を正規の場所として置く必要があります。

チームプロジェクト

チームグループのプロジェクトは特定のチームワークフローをサポートするプロジェクトです。ステータス収集、プロジェクトトリアージ、および同様のチーム向けプロジェクトはここに追加する必要があります。これらのプロジェクトにはチームの機密情報が含まれる可能性があるため、正規の場所は ops.gitlab.net にできます。この判断はチームの裁量に委ねられています。

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