GitLab リポジトリ
GitLab は多くのサブプロジェクトで構成されています。GitLab プロジェクトの厳選されたリストは GitLab エンジニアリングプロジェクトページで確認できます。
目的
このページの目的は、組織内で GitLab リポジトリを作成・管理するための包括的なガイダンスを提供することです。すべての GitLab プロジェクトが一貫したセキュリティ、ガバナンス、運用要件に準拠するよう、標準化された手順とベストプラクティスを定めています。これらのガイドラインに従うことで、チームはリポジトリを適切に構造化し、適切なアクセス制御を実装し、必須の CI/CD 設定を構成し、コードベースとより広い GitLab エコシステムを保護するセキュリティ対策を組み込むことができます。
新しいプロジェクトの作成
新しいプロジェクトを作成する際は、以下のステップに従ってください:
ドッグフーディングに関する私たちのスタンスを読んで理解してください。私たちのような人々のためのツールを構築する製品開発組織の一員として、GitLab プロジェクトに機能やツールを追加することがデフォルトです。これは労力が 2〜5 倍かかる場合でも同様です。それでも GitLab 外にプロジェクトを作成する必要があると感じる場合は、このプロセスに従って決定を記録してください。
プロジェクトが以下のサブグループ配下にあることを確認してください:
- アプリケーションに関連するものには
gitlab-org - 厳密に会社関連のものには
gitlab-com
コンテキストと権限継承の複雑さを避けるため、これらのルートネームスペース直下(例:
gitlab-org/NEW_PROJECT)にプロジェクトを作成することは推奨されません。必要な場合はメンテナーのみが作成できますが、前述の理由から避けるべきです。 作成権限がない場合は、アクセスリクエスト Issue を作成し、メンテナー(gitlab-org および gitlab-com)に承認を求めてください。- アプリケーションに関連するものには
プロジェクトリポジトリのデフォルトブランチ名として
mainを使用するよう設定します。リポジトリにライセンスを追加してください。どのライセンスを追加するかは #legal に確認してください。サンプルライセンスはこちらです:
gitlab-org/gitlabMIT Licenseただし使用前に法務に確認してください。リポジトリの
CONTRIBUTING.mdに「Developer Certificate of Origin and License」というセクションを追加してください。gitlab-org/gitalyDCO + License セクションをそのままコピー&ペーストするのが最も簡単です。コントリビューションガイドに関連する詳細情報を追加してください。コントリビューション例を参照してください。
プロジェクトの
README.mdからCONTRIBUTING.mdへのリンクを追加してください。CODEOWNERS ファイルを追加して、コントリビューターが変更のレビューに最適なチームを見つけやすくしてください。
- 時間の経過とともに自動更新され、休暇を取る人にも対応できるよう、個人ではなくチームをオーナーとして使用してください
- 所有権をサブディレクトリや個別ファイルにスコープできますが、少なくとも新しいファイルや明示的に記載されていないファイルのトップレベルのキャッチオールを含めてください。
可能であれば、プロジェクトで以下のマージリクエスト設定を有効にしてください:
可能であれば、プロジェクトで以下のパイプライン設定を有効にしてください:
プロジェクトには、MR 承認ルールと保護ブランチ設定の最小ベースライン設定が必要です。
プロジェクトには
ユーザーがアクセスをリクエストできる設定を無効化して、意図しない外部アクセスの付与を防ぎます。必要に応じて、デフォルトの CI/CD 設定をセットアップしてください。
プロジェクトが顧客に出荷される作業の一部である場合、そのファイルへの MR を開くかエンジニアリングプロダクティビティの定めるプロセスに従って projects_part_of_product.csv に追加してください。
AppSec が新しいプロジェクトを分類できるよう協力してください。
適切なセキュリティスキャナーを有効にしてください。
Renovate へのオンボーディング(https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot)と、定期的に発見事項をトリアージして依存関係を更新するプロセスのセットアップをしてください。
リポジトリが公開の場合は、セキュリティミラーを設定してください。 これはセキュリティ脆弱性が修正される前に公開されることなく対処するために必要です。
既存のリポジトリの設定を変更する際は、コミュニケーションを念頭に置くことが重要です。Issue で変更を議論し、関連するチャットチャンネル(例: #development)でアナウンスするだけでなく、Engineering Week-in-Review ドキュメントでのアナウンスも検討してください。これは GitLab リポジトリへの変更では特に重要です。
CI/CD 設定
以下は、gitlab-org および gitlab-com グループ配下のすべてのプロジェクトで使用すべきデフォルトの .gitlab-ci.yml 設定です:
include:
- template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'
default:
tags:
- gitlab-org
stable/security ブランチをサポートする必要があるプロジェクトは、代わりに以下を使用してください:
workflow:
rules:
# For merge requests, create a pipeline.
- if: '$CI_MERGE_REQUEST_IID'
# For `master` branch, create a pipeline (this includes on schedules, pushes, merges, etc.).
- if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
# For tags, create a pipeline.
- if: '$CI_COMMIT_TAG'
# For stable, and security branches, create a pipeline.
- if: '$CI_COMMIT_BRANCH =~ /^[\d-]+-stable(-ee)?$/'
- if: '$CI_COMMIT_BRANCH =~ /^security\//'
default:
tags:
- gitlab-org
これにより:
- MR、
master、タグのみでパイプラインを作成するworkflowが含まれます。 - デフォルトで使用される
gitlab-orgタグが定義されます。これはコスト最適化されたランナーに対応し、Docker サポートはありません。Docker サポートが必要なジョブはgitlab-org-dockerタグを使用します。
Docker の使用が必要なジョブは、gitlab-org-docker タグを使用して特定のジョブのコンテキストのみで定義する必要があります:
sast:
tags:
- gitlab-org-docker
Windows の使用が必要なジョブは、Windows 上の SaaS ランナーを使用してください。正確な設定については、Windows 上の SaaS ランナーのドキュメントを参照してください。
プロジェクトの公開
プロジェクトをパッケージリポジトリに公開するには、これらの手順に従ってください。
さらなるセキュリティに関する推奨事項
- シークレットをプレーンテキスト変数として保存したり、包括的なシークレット管理のためにマスクされた環境変数に依存したりしないでください。代わりに外部シークレットストレージソリューションを設定してください。
- プロジェクトの脅威モデルの作成を強く検討してください。
- プロジェクトが成熟したら、AppSec レビューのリクエストを検討してください。
- さらなる質問については、AppSec チーム(
@gitlab-com/gl-security/appsecおよび#security_help)に連絡してください。
