GitOps を使用してソースでセキュリティを適用する方法

GitOps デプロイ モデルにセキュリティ上の問題がある場合 (たとえば、入力ミスによる権限の構成ミスなど)、これは実行時に発見されるまで伝播され、ほとんどのセキュリティ イベントがスキャンまたは検出されます。

インフラストラクチャの潜在的なセキュリティ問題をソースで修正できるとしたら?

基本から始めましょう。

ギットとは？

Gitは、オープン ソースの分散型バージョン管理システムです。ファイル (通常はソース コードなどのテキスト ファイル) で行われた変更を追跡し、共同作業モデルを可能にし、促進します。これは、今日のバージョン管理システムの事実上の標準です。

ラップトップでローカルに独自の git リポジトリを作成したり、独自のサーバーでホストしたり、GitLab や GitHub などのプロバイダーを使用したりできます。

リポジトリの管理方法にはさまざまな「フロー」がありますが (git-flow、github-flow など)、git の使用方法の基本的な例は次のようなものです。 ファイルの変更は、ユーザーによって「コミット」されます。リポジトリを「フォーク」し、「ブランチ」で適切な変更を行います。

次に、ユーザーはリクエスト (「プル リクエスト」、「マージ リクエスト」、または「パッチの送信」のいずれか) を作成して、それらの変更をリポジトリに含めます。

その後、通常は「所有者」とリクエストを作成したユーザーの間で話し合いが行われ、問題がなければ変更が受け入れられ、リポジトリに追加されます。

注: 詳細を知りたい場合は、git プル リクエスト メカニズムに関するより詳細な情報を参照してください。

実際の例を確認するには、お気に入りのオープン ソース GitLab または GitHub リポジトリを参照し、[プル リクエスト] (または [マージ リクエスト]) タブを参照します (または、楽しいものについてはこちらを参照してください)。提案された変更、コメント、ラベル、変更を提案した人、提案された変更に対して検証を実行しているツール、リポジトリを見ている人に送信された通知などを確認できます。

GitOps とは何ですか?

簡単に言うと、 GitOps は、ソフトウェア資産の信頼できる唯一の情報源として git リポジトリを使用する方法論にすぎないため、git デプロイ モデル (プル リクエスト、ロールバック、承認など) をソフトウェアに活用できます。

書籍 ( The Path to GitOps 、 GitOps and KubernetesまたはGitOps Cloud-native Continuous Deployment )、ホワイトペーパー、数え切れないほどのブログ投稿がありますが、物事がどのように進化したかを簡単に見て、 GitOpsの目的を詳しく説明しましょう。ここ数年で。

クラウドが登場する前は、アプリケーションをホストする新しいサーバーを追加するのに数週間かかりました。許可を求めて購入し、多くの手動タスクを実行する必要がありました。その後、仮想化によって物事がはるかに簡単になりました。いくつかのスペックを持つ仮想マシンをリクエストすると、数分後にアクセスできるようになります。

次に、クラウド。サーバー、ネットワーク、ストレージ、さらにはデータベース、メッセージング キュー、コンテナー、機械学習、サーバーレスなどの要求は、API 呼び出しだけで行うことができます。あなたはそれを要求し、数秒後にそれを取得します。使用した分だけ支払う必要があります。これはまた、API 呼び出しを実行するコードとしてインフラストラクチャを管理できることを意味します...そして、コードをどこに保存しますか? git リポジトリ (またはその他のコンテンツ バージョン システム)。

GitOps という用語は、 2017 年に Weaveworks によって造られました。OpenGitOpsを言い換えると、GitOps システムは次の原則に基づいています。

• 宣言的 : 「何」を定義します。
• バージョン管理され、不変: したがって、「git」。
• 自動的にプル: エージェントは、望ましい状態とコードで発生する変更を監視します。
• 継続的に調整: 誰かが Kubernetes について言及しましたか?

GitOps 方法論の本質は、基本的にはクラスター上で実行されている Kubernetes コントローラーまたはコントローラー(またはエージェント) であり、その上で実行されている Kubernetes オブジェクト ( CustomResourceによって定義されている) を監視し、現在の状態を Git repo で指定された状態と比較します。一致しない場合は、リポジトリで見つかったマニフェストを適用してアプリケーションを修正します。

注: GitOps には、プッシュとプル、構成管理の処理方法など、わずかに異なるアプローチがあります。これらは高度なトピックですが、ここでは基本に固執しましょう。

次の図は、簡略化された GitOps システムを示しています。

• コードの変更は、ユーザーによって Git リポジトリに送信されます。
• 次に、リポジトリでプロセスがトリガーされ、それらの変更がアプリケーション自体に組み込まれます。これには、その新しいコードに対して自動化ツールを実行して検証することも含まれます。
• すべてが整ったら、リポジトリを監視している Kubernetes クラスターで実行されている GitOps エージェントが、望ましい状態 (リポジトリ内のコード) と現在の状態 (Kubernetes クラスター自体で実行されているオブジェクト) との間の調整を実行します。

Git ベースであることは、開発者にとって摩擦がないことを意味します。対話する新しいツールについて心配する必要はありませんが、Git リポジトリでコードを管理するために使用されるのと同じプラクティスを適用します。

GitOps ツールについて言えば、 FluxやArgoCDなどのオープン ソース ツールを含むいくつかのツールが既に利用可能であり、どちらもCNCF のインキュベーション プロジェクトです。

GitOps を介してアプリケーション定義がどのように見えるかを理解するために、これは Flux または ArgoCD によって管理される単純なアプリケーション (GitHub リポジトリに格納されている) の例です。

フラックスあり:

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

ArgoCD の場合:

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

どちらも、アプリケーション マニフェストが格納されている Git リポジトリ (デプロイ)、名前空間、およびその他の詳細を参照します。

GitOps と IaC の比較

コードとしてのインフラストラクチャは、さまざまな手法とツールを使用して、インフラストラクチャのビルディング ブロックをコードとして扱う方法論です。これは、VM、コンテナ、ネットワーク、ストレージなどのインフラストラクチャを、お気に入りのインフラストラクチャ プロバイダーの Web インターフェイスを介して手動で作成する代わりに、コードとして定義し、選択したツールによって作成/更新/管理されることを意味します。 terraform 、 crossplane 、またはpulumiなど。

メリットは非常に大きいです。インフラストラクチャをコードのように管理し (現在はコードです)、開発のベスト プラクティス (自動化、テスト、トレーサビリティ、バージョン管理など) をインフラストラクチャ資産に活用できます。実際、「ソフトウェアとしてのインフラストラクチャ」という用語を代わりに使用する傾向があります。これは、単なるコード以上のものであるためです。

このトピックに関する情報は山ほどありますが、 次のリソースが出発点として適切です。

ご想像のとおり、GitOps は Infrastructure as Code を宣言型モデルとして利用してインフラストラクチャを定義します。実際、IaC は GitOps の基礎の 1 つです。しかし、IaC は GitOps の残りの原則を義務付けていないため、それだけではありません。

GitOps 対 DevOps

「DevOps」という用語には多くの定義があります。誰に尋ねるかにもよりますが、簡単に言えば、「DevOps とは、摩擦を減らして高速にソフトウェアを構築して提供するためのプラクティスとツールの組み合わせです。」

GitOps は DevOps プラクティスに一致するフレームワークを提供するため、DevOps 方法論は GitOps を活用できますが、厳密には必要ではありません。

NoOpsはどうですか？

NoOps は2021 年に Forrester によって造られました。これは、IT 環境が抽象化され、手動で管理する必要がなくなるまで自動化された運用を処理するための根本的なアプローチです。

GitOps は、Git リポジトリで目的の状態に修正することで手動の変更を減らすのに役立ちますが、IT 環境全体に実際の NoOps を適用することは、現時点では実際の目標ではなく、野心的な目標です。

GitOps は Kubernetes 専用ですか?

いいえ。Kubernetes、コントローラー パターン、および Kubernetes オブジェクトを定義する宣言型モデルは、GitOps 方法論に完全に一致しますが、GitOps 方法論を Kubernetes なしで適用できないという意味ではありません。 Kubernetes の外部で GitOps を使用する場合、冪等性の処理、アセットの削除/作成、シークレット管理など、いくつかの課題があります。しかし、GitOps の原則は Kubernetes なしで適用できます(そして少しの創造性を適用します)。

GitOps とセキュリティ

ここで、セキュリティの側面について話しましょう。ほとんどのセキュリティ ツールは、潜在的な脆弱性と問題を実行時に検出します (遅すぎます)。それらを修正するには、リアクティブな手動プロセスを実行する必要があります (例: kubectl edit を使用して k8s オブジェクトのパラメーターを直接変更する) か、理想的には修正がソースで行われ、サプライ チェーン全体に伝播されます。これが「シフトセキュリティレフト」と呼ばれるものです。手遅れになったときに問題を修正することから、問題が発生する前に修正することまで。

これは、すべてのセキュリティ問題をソースで修正できるという意味ではありませんが、セキュリティ レイヤーをソースに直接追加することで、いくつかの問題を防ぐことができます。

まず、一般的なセキュリティの推奨事項が適用されます。

• 攻撃面を減らす
• シークレットを暗号化する (外部シークレットまたは封印されたシークレットを使用)
• ネットワークのセグメンテーション
• RBAC
• ソフトウェアを最新の状態に保つ
• 最小権限を強制する
• 監視と測定
• …

GitOps 方法論が一般的にセキュリティを向上させるいくつかのシナリオを見てみましょう。

• 手動変更を回避/拒否する (ドリフトを回避する) 。 Git リポジトリは信頼できる情報源です。アプリケーション定義を変更しようとすると、GitOps ツールは Git リポジトリに保存されているバージョンを適用することで、これらの変更を元に戻します。

• 変更のロールバック。アプリケーションのデプロイでいくつかのパラメーターを変更することにより、特定のコミットに潜在的なセキュリティの問題が発生したとします。 Git 機能を利用して、必要に応じてソースで直接変更をロールバックできます。GitOps ツールは、ユーザーの操作なしでアプリケーションを再デプロイします。

• 早い反応。アプリケーション (MariaDB など) で脆弱なコンテナー イメージを使用している場合は、PR を作成してタグをデプロイ ファイルに更新するだけで、GitOps ツールは新しいデプロイで新しいタグを使用します。

• トレーサビリティ。 Git 機能を使用すると、ファイルがいつ変更されたか、変更自体、および変更をプロモートしたユーザーを簡単に確認できます。監査ログを無料で入手できます。

• 災害からの回復。繰り返しになりますが、Git リポジトリは信頼できる情報源です。何かが起こったためにアプリケーションを再デプロイする必要がある場合、定義はそこにあります (もちろん、データ自体など、他のものに対する災害復旧計画を立てる必要があります)。
• アクセス制御。 Git リポジトリのさまざまなユーザーにさまざまな権限を適用したり、「2 つの肯定的なレビューの後にのみ変更をマージする」などのポリシーを適用したりできます。

これらの利点は、GitOps の方法論を使用してセキュリティ体制を改善することを正当化するのに十分なものであり、すぐに使用できるものですが、GitOps はさらにいくつかのものを組み合わせたものです。もっと多くのことができます。 GitHub、GitLab、およびその他の Git リポジトリ プロバイダーを使用すると、プル リクエストを含め、Git リポジトリで実行した変更に基づいてアクションまたはパイプラインを実行できるため、可能性は無限大です。いくつかの例:

• リンティング。アプリケーションの定義は code です。間違った構文やパラメーターの欠落などがないか定義をチェックするとどうなるでしょうか?実行した変更に対して実行できるツール ( megainterなど) があるため、後で驚くことを避けることができます。

• テスト。一時的な Kubernetes クラスターの作成を自動化して、変更を加えてアプリケーションを実行し、それに対していくつかのテストを実行することもできます。

• 脆弱性スキャン。環境にデプロイする前に、使用しているコンテナー イメージの脆弱性をチェックします。

• コードとしてのポリシー。 OPAを利用して、マニフェストにポリシーを適用して、潜在的な問題やカスタム ポリシーをチェックすることもできます

最終的な考え

GitOps 方法論は、展開モデルにいくつかの改善をもたらし、別のツールを追加する必要なく、テーブルにセキュリティ上の利点をもたらします。

「シフト レフト」レイヤーをソース コードに直接追加することでセキュリティ体制を改善します。また、プル リクエスト モデルの柔軟性のおかげで、ランタイムに影響を与えたり変更したりすることなく、追加のセキュリティ チェックを簡単に追加できます。

ここにも掲載されています。