機密情報が漏洩したかどうかを迅速に把握
認証情報を共有リポジトリに誤ってコミットすると、重大な結果を招く可能性がありますが、これは単純なミスです。攻撃者はパスワードや API キーを一旦入手すると、あなたのアカウントを乗っ取り、不正に課金することができます。 これは、乗っ取られたアカウントから他のアカウントへのアクセスされる、ドミノ効果につながることさえあります。リスクが非常に高いため、機密情報が漏洩した場合にはできるだけ早く知ることが最も重要です。
今回のリリースでは SAST 機能の一部として 機密情報の検出 を導入しています。CI/CD ジョブで各コミットをスキャンし、機密情報が含まれていないことを確認します。 スキャンにより機密情報を検出した場合、開発者はマージリクエストで警告を受け、漏洩した資格情報を無効にして新しい資格情報を生成するためのアクションを迅速に実行できます。
適切な変更管理の実施
組織が成長し、より複雑になるにつれて、組織のさまざまな部署間で整合性を保つことが難しくなります。同時に、アプリケーションのユーザ数と収益が増加すると、不適切なコードやセキュアでないコードをマージした場合の影響も大きくなります。適切なレビュープロセスに従っていることをコードがマージされる前に確認することは、そうしない場合のリスクが非常に大きいため、多くの組織にとって難しい要件です。
GitLab 11.9 では マージリクエストの承認ルール を利用して、より高度な制御と機構を提供しています。 これまでは、必要な承認のために個人またはグループを指定できました (グループのどのメンバーでも承認を与えることができます)。現在は、マージリクエストに複数のルールを追加して、個々の承認者に個別に要求したり、特定のグループで複数の承認者を要求することもできます。さらに、承認ルールにコードオーナ機能が統合されているため、誰が承認すべきかを簡単にトラッキングできます。
これにより、組織では複雑な承認フローを実現することができます。課題、コード、パイプライン、監視データを可視化してアクセスできる GitLab の単一アプリケーションのシンプルさを維持しながら、決定を通知して承認を迅速化することができます。
GitLab.com では承認ルールが一時的に無効になっていましたが、リグレッション のため GitLab 11.9 ではデフォルトで有効になっていません。
ChatOps がオープンソースになりました
GitLab ChatOps は強力な自動化ツールで、どんな CI/CD ジョブでも実行でき、Slack や Mattermost のようなチャットアプリから直接 CI/CD ジョブのステータスを受け取ることができます。GitLab 10.6 で最初にリリースされた ChatOps は GitLab Ultimate 向けの機能でした。GitLab 社の 製品戦略 および オープンソースへの取り組み の一環として、上位プランの機能を下位のプランでも利用できるように定期的に見直しを実施しています。
ChatOps では、これは誰もが恩恵を受けられる機能であり、またこの機能自体がコミュニティからの貢献による恩恵を受けることができると判断しました。
GitLab 11.9 では ChatOps をオープンソース化 しているので GitLab セルフマネージド版の Core プランと GitLab.com SaaS版の Free プランで利用することができ、コミュニティへのコントリビューションも可能です。
その他
このリリースでは、フィーチャーフラグの監査, 脆弱性修正のマージリクエスト, セキュリティジョブ用の CI/CDテンプレート など多くの優れた機能を利用できます。それら全ての機能を知るには、この記事をお読みください。
GitLab 11.9での主要機能
リポジトリ内の API キーなどの機密情報を検知
CORE
STARTER
PREMIUM
ULTIMATE
アプリケーション開発時に常に発生する懸念として、開発者が意図せずに API キーなどの機密情報を自分のリモートリポジトリにコミットする可能性が挙げられます。 そのソースに他者がアクセスできる場合やプロジェクトが公開されている場合、機密情報が公開されてしまい、それを利用して悪意のあるユーザがデプロイ環境などのリソースにアクセスする可能性があります。
GitLab 11.9 には Secret Detection と呼ばれる新しいチェックが含まれています。リポジトリ内のコンテンツをスキャンして、API キーなどのリポジトリに存在してはならない情報を検知します。GitLab ではマージリクエストウィジェット、パイプラインレポート、およびセキュリティダッシュボードの SAST レポートに結果を表示します。
アプリケーションで SAST が既に有効になっている場合は、この新機能の恩恵を受けるために特に何かをする必要はありません。すでに Auto DevOps のデフォルト設定にも含まれています。
非推奨
GitLab Geo で Hashed Storage を適用 (GitLab 12.0)
GitLab Geo ではセカンダリノードの競合状態を緩和するために Hashed Storage が必要です。 これは gitlab-ce#40970 に記載されています。
この要件は GitLab 11.5 で gitlab-ee#8053 にある Geo のドキュメントに追加されました。
GitLab 11.6 では sudo gitlab-rake gitlab:geo:check
コマンドを用いて、ハッシュストレージが有効であり、すべてのプロジェクトが移行されていることを確認できます。gitlab-ee#8289 を参照してください。 Geo を使用している場合は、このチェックを実行してできるだけ早く移行してください。
GitLab 11.8 では上記のチェックが出来ていない場合 Admin Area › Geo › Nodes ページに警告が表示されます: gitlab-ee!8433
GitLab 12.0 では Geo で Hashed Storage 要件を適用する予定です。gitlab-ee#8690 を参照してください。
削除日: 2019年6月22日
Hipchat 統合機能について
Hipchat は 提供終了しています。 そのため、11.9 では既存の GitLab Hipchat 統合機能を削除しました。
削除日: 2019年3月22日
Docker executor を使用した GitLab Runner での Cent OS 6 サポートについて
GitLab 11.9 では Docker executor を使用している場合の CentOS 6 での GitLab Runner サポートを削除します。これは CentOS 6 がサポート対象外となった Docker ライブラリへのアップグレードによるものです。詳細については この課題 を参照してください。
削除日: 2019年3月22日
GitLab Runner での legacy code パスを廃止
Gitlab 11.9 以降、GitLab Runner はリポジトリのクローン作成/取得に 新しい方法 を使用しています。現在 GitLab Runner は新しい方法がサポートされていない場合に古い方法を使用します。
GitLab 11.0 では GitLab Runner 用の Metrics Server 設定方法を変更しました。metrics_server
は GitLab 12.0 で導入される listen_address
のために削除されます。詳細については この課題 と この課題 を参照してください。
11.3 では GitLab Runner での 複数キャッシュプロバイダー のサポートを開始しました。これにより S3 固有の設定 に新しい設定が追加されました。 ドキュメント には、何が変わったのか、そして新しい設定にどう対応するのかをまとめた表があります。詳細は この課題 を参照してください。
これらのパスは GitLab 12.0 では使用できなくなります。GitLab Runner 12.0 にアップグレードするときにユーザーがやるべきことは GitLab インスタンス上の GitLab のバージョンが 11.9 以上であることを確認するだけです。他は何も変更する必要はありません。
削除日: 2019年6月22日
GitLab Runner の entrypoint フィーチャーフラグを廃止
GitLab Runner は 11.4 にて #2338 や #3536 のような課題に対応するために FF_K8S_USE_ENTRYPOINT_OVER_COMMAND
という feature フラグを導入しました。
GitLab 12.0 ではフィーチャーフラグがオフになっているかのように正しい挙動に切り替わります。詳細については この課題 を参照してください。
削除日: 2019年6月22日
GitLab Runner で EOL になった Linux ディストリビューションのサポートを廃止
GitLab Runner をインストールできるいくつかの Linux ディストリビューションがサポート終了となりました。
GitLab 12.0 では、GitLab Runner はこれらの Linux ディストリビューションに対してパッケージを配布しなくなります。サポートされなくなったディストリビューションの完全なリストは このドキュメント にあります。 Javier Jardón さんの コントリビューション に感謝します。
削除日: 2019年6月22日
GitLab Runner Helper の古いコマンドを削除
Windows Docker executor をサポートする取り組みの一環として、helper イメージ で使用されていたいくつかの古いコマンドを廃止する必要がありました。
GitLab 12.0 では、GitLab Runner が新しいコマンドを使うようになります。これは helper イメージを上書きしている ユーザにのみ影響します。 詳細については この課題 を参照してください。
削除日: 2019年6月22日
保護されていないブランチでの Git タグのリリースノートの削除や修正はこれまで Maintainer と Owner に制限されていました。
開発者はタグを追加したり、保護されていないブランチを修正したり削除したりできるので、Git タグも削除できるべきです。 GitLab 11.10 では、私たちのパーミッションモデルに この変更を追加 して、ワークフローを改善し、開発者がより効率良くタグを利用できるようにしています。
引き続き、Maintainer と Owner にこのパーミッションを制限したい場合には、保護されたタグ を使うことができます。
削除日: 2019年4月22日
Omnibus GitLab での Prometheus 1.x サポート
Omnibus GitLab にバンドルされる Prometheus は GitLab 11.4 では 1.0 バージョンが廃止されて 2.0 にアップグレードされた Prometheus が含まれるようになりました。 ただし、メトリクスのフォーマットは 1.0 と互換性がありません。既存のインストールでは 2.0 にアップグレードできますが、その際オプションで 付属のツールを使用 してデータ移行できます。
GitLab 12.0 では、まだ Prometheus 2.0 が動作していない場合は自動的にアップグレードされます。Prometheus 1.0 からのメトリクスデータは移行されずに失われます。
削除日: 2019年6月22日
TLS v1.1 について
セキュリティを強化するために GitLab 12.0 から TLS v1.1 はデフォルトで無効になります。これにより、Heartbleed を含む多くの問題が緩和され、GitLab は PCI DSS 3.1 標準にすぐに準拠できるようになります。
TLS v1.1 を直ちに無効にしたい場合は、gitlab.rb
ファイルに nginx['ssl_protocols'] = "TLSv1.2"
を設定し gitlab-ctl reconfigure
を実行してください。
削除日: 2019年6月22日
GitLab をインストールするための OpenShift テンプレート
公式の gitlab
helm chart は OpenShift でのデプロイメント を含めて、Kubernetes 上で GitLab を運用するための推奨方法です。
GitLab インストール用の OpenShift テンプレート は廃止され、GitLab 12.0 では未サポートになります。
削除日: 2019年6月22日
以前のセキュリティジョブ定義について
セキュリティジョブ用の CI/CD テンプレート の導入により、以前のジョブ定義を廃止し、GitLab 12.0 以降で削除予定です。
GitLab が提供するすべての新しいセキュリティ機能を活用するためにジョブ定義を新しい構文に更新してください。
削除日: 2019年6月22日
admin パネルのシステム情報セクションについて
GitLab は稼働中の GitLab インスタンスに関する情報を admin/system_info
に表示しますが、この情報は不正確かもしれません。
GitLab 12.0 では admin パネルの このセクションを削除 予定であり、他のモニタリング機能 の使用をお勧めします。
削除日: 2019年6月22日