ある場合 (たとえば、入力ミスによる権限の構成ミスなど)、 、ほとんどのセキュリティ イベントがスキャンまたは検出されます。 GitOps デプロイ モデルにセキュリティ上の問題が これは実行時に発見されるまで伝播され インフラストラクチャの潜在的なセキュリティ問題をソースで修正できるとしたら? 基本から始めましょう。 ギットとは？ です。ファイル (通常はソース コードなどのテキスト ファイル) で行われた変更を追跡 ます。これは、今日のバージョン管理システムの事実上の標準です。 は、オープン ソースの分散型バージョン管理システム Git し、共同作業モデルを可能にし、促進し ラップトップでローカルに独自の git リポジトリを作成したり、独自のサーバーでホストしたり、GitLab や GitHub などのプロバイダーを使用したりできます。 リポジトリの管理方法にはさまざまな「フロー」がありますが (git-flow、github-flow など)、git の使用方法の基本的な例は次のようなものです。 ファイルの変更は、ユーザーによって「コミット」されます。リポジトリを「フォーク」し、「ブランチ」で適切な変更を行います。 次に、ユーザーはリクエスト (「プル リクエスト」、「マージ リクエスト」、または「パッチの送信」のいずれか) を作成して、それらの変更をリポジトリに含めます。 その後、通常は「所有者」とリクエストを作成したユーザーの間で話し合いが行われ、問題がなければ変更が受け入れられ、リポジトリに追加されます。 注: 詳細を知りたい場合は、git プル リクエスト メカニズムに関するより詳細な情報を参照して 。 ください 実際の例を確認するには、お気に入りのオープン ソース GitLab または GitHub リポジトリを参照し、[プル リクエスト] (または [マージ リクエスト]) タブを参照します (または、楽しいものについては を参照してください)。提案された変更、コメント、ラベル、変更を提案した人、提案された変更に対して検証を実行しているツール、リポジトリを見ている人に送信された通知などを確認できます。 こちら GitOps とは何ですか? 簡単に言うと、 ため、git デプロイ モデル (プル リクエスト、ロールバック、承認など) をソフトウェアに活用できます。 GitOps は、ソフトウェア資産の信頼できる唯一の情報源として git リポジトリを使用する方法論にすぎない 書籍 ( 、 または )、 、数え切れない が、物事がどのように進化したかを に見 、 の目的を詳しく説明しましょう。ここ数年で。 The Path to GitOps GitOps and Kubernetes GitOps Cloud-native Continuous Deployment ホワイトペーパー ほどの ブログ投稿 があり ます 簡単 て GitOps クラウドが登場する前は、アプリケーションをホストする新しいサーバーを追加するのに数週間かかりました。許可を求めて購入し、多くの手動タスクを実行する必要がありました。その後、仮想化によって物事がはるかに簡単になりました。いくつかのスペックを持つ仮想マシンをリクエストすると、数分後にアクセスできるようになります。 次に、クラウド。サーバー、ネットワーク、ストレージ、さらにはデータベース、メッセージング キュー、コンテナー、機械学習、サーバーレスなどの要求は、API 呼び出しだけで行うことができます。あなたはそれを要求し、数秒後にそれを取得します。使用した分だけ支払う必要があります。これはまた、API 呼び出しを実行するコードとしてインフラストラクチャを管理できることを意味します...そして、コードをどこに保存しますか? git リポジトリ (またはその他のコンテンツ バージョン システム)。 GitOps という用語は、 言い換えると、GitOps システムは次の原則に基づいています。 2017 年に Weaveworks によって造られました。OpenGitOps を 的 : 「何」を定義します。 宣言 : したがって、「git」。 バージョン管理され、不変 : エージェントは、望ましい状態とコードで発生する変更を監視します。 自動的にプル : 誰かが Kubernetes について言及しましたか? 継続的に調整 (またはエージェント) であり、その上で実行されている Kubernetes オブジェクト ( によって定義されている) を監視 。一致しない場合は、リポジトリで見つかったマニフェストを適用してアプリケーションを します。 GitOps 方法論の本質は、基本的にはクラスター上で実行されている 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 は に Forrester によって造られました。これは、IT 環境が抽象化され、手動で管理する必要がなくなるまで自動化された運用を処理するための根本的なアプローチです。 2021 年 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 方法論は、展開モデルにいくつかの改善をもたらし、 別のツールを追加する必要なく、テーブルにセキュリティ上の利点をもたらします ます。また、プル リクエスト モデルの柔軟性のおかげで、ランタイムに影響を与えたり変更したりすることなく、追加のセキュリティ チェックを簡単に追加できます。 「シフト レフト」レイヤーをソース コードに直接追加することでセキュリティ体制を改善し も掲載されています。 ここに
