2022年5月10日

Continuous Delivery

OPAが提供するHarness Policy as Codeのご紹介

ここにあります。Harness Policy as Codeは、デプロイメントやインフラストラクチャなどに対するポリシーの作成と適用を支援し、コンプライアンスと標準を犠牲にすることなく開発者の生産性を向上させることができます。
 

62d0ef3b81fb9e387d2da6eb_02.-Design_Blog-header-14.png

Harness Policy as Codeは、Open Policy Agent (OPA)を利用した集中型ポリシー管理・ルールサービスで、すべてのデリバリーパイプラインとプロセスに適用されるポリシーを一元的に定義・監視することができます。Harness Policy as Codeは、デプロイメントやインフラストラクチャなどに対するポリシーの作成と適用を支援し、コンプライアンスや標準を犠牲にすることなく開発者の生産性を向上させることができます。

Harness Policy as Codeは、スタック全体でポリシーを作成および適用するための、使いやすく拡張性の高いソリューションであるOPAをベースにしています。OPAは、Cloud Native Computing Foundation(CNCF)に認められたオープンソースプロジェクトで、多くのソフトウェアデリバリーのユースケースで広く採用されています。ポリシーは宣言型コードとして記述されるため、単純なものから複雑なユースケースまで、理解しやすく、修正も容易です。

Harness Policy as Codeは、CI、CD、Feature Flagsと統合され、自動承認、拒否、その他の高度なパイプライン機能を実行します。詳しくは、技術ドキュメントをご覧ください。

ソフトウェアデリバリーでポリシーマネジメントが必要な理由

企業内でDevOpsが採用されると、通常、1つのチームがソフトウェアの配信とプロセスを作成し、維持します。そのチームは、社内のDevOpsプロセスの「創造者」であるため、完全なコントロールと可視性を持っています。社内でDevOpsを採用する事業部が増えるにつれ、その起点となるチームの手動プロセスがボトルネックとなり、チームの自律性を制限しソフトウェアデリバリーを遅らせることでイノベーションを阻害する可能性があります。

 ボトルネックを解消し、ベロシティを向上させるために、企業は、開発チームに独自のDevOpsプロセスの推進を許可することで、より多くの自律性を与えることができます。そのプロセスコントロールの分散化は、企業にとってより多くのリスクをもたらす可能性があります。

ガバナンスが分散化すると、開発チームは品質チェックや承認を怠ったり、脆弱性を持ち込んだり、コンプライアンスを破ったりする可能性があります。組織は、自律性とガバナンスのバランスをとる必要があります。そうすれば、すべてのコンプライアンス標準とセキュリティ・ポリシーを遵守しているという確信を持って、チームに権限を与えることができます-すべてはイノベーションを減速させることなく。

金融サービスや医療などの規制産業では、コンプライアンスがさらに重要になります。これは、企業の標準だけでなく、SOC2、PCI、FedRampなどのサードパーティの規制にも当てはまります。すべてのソフトウェアデリバリパイプラインは、完全な監査可能性をもってコンプライアンス標準に適合することが不可欠です。

DevOpsプロセス全体のポリシーの集中管理とガバナンスにより、企業は組織全体の標準を定義し、規制へのコンプライアンスを強化することができます。ポリシーによって、個々のチームは、標準から外れることを防ぐための監視とガードレールを備えた上で、プロセスの自律性を持つことができ、安全でコンプライアンスに準拠したソフトウェア配信を実現します。

コード機能としてのハーネスポリシー

Harness Policy as Codeは、OPAを活用した集中型のポリシー管理およびルールサービスで、ソフトウェアデリバリー全体のコンプライアンス要件を満たします。HPEは、すべてのデリバリーパイプラインとプロセスに適用されるポリシーを一元的に定義および監視できるようにします。

ポリシーを書き、実行するためのPolicy as Codeの機能には、以下のようなものがあります。

  • 開発者がポリシー・アズ・コードを素早く書き始めることができるポリシー・エディターです。ポリシーのライブラリとテスト端末を使用することで、開発者はポリシーを有効にする前に、実際の入力でポリシーを試すことができます。
  • Harnessのプロセスで自動的に適用されるように設定されたポリシー(パイプラインの実行時、Feature Flagの保存時など)。
  • 重大度の設定:ポリシー違反の場合、警告やエラーでプロセスの継続を停止させることができます。
  • 監査証跡:監査とコンプライアンスに必要な詳細なアウトプットとともに、ポリシー評価の全履歴を維持することができます。

 

62d0ef393a9c5f95a30e775c_image-6-1024x501.png

カスタマイズ可能なサンプルポリシー。

Policy as Codeのリリースにより、CIやCDパイプライン、Feature Flagsにポリシーを適用することが可能になりました。

パイプラインポリシーは、デリバリーパイプラインの要件を管理し、パイプラインの保存時やトリガー時、あるいはパイプラインの実行中であっても自動的に適用することが可能です。ポリシーは、特定のパイプラインの設定、高度なアクセス制御のユースケース、ランタイム検証などを強制することができます。以下は、Policy as Codeでできることの例です。

  • 本番環境へのデプロイメント前に承認ステップを必要とする。
  • パイプラインでのシェルスクリプトの使用を禁止する。
  • 承認されたネームスペースへのデプロイメントのみを許可する。
  • 承認されたコンテナレジストリからのデプロイメントのみを許可する。
  • パイプラインの継続を許可する前に、テスト ステップの結果が最小限のしきい値を満たしていることを検証する。

 

62d0ef39f0c56e6bc7433c3e_image-7-1024x473.png

ポリシー違反のため、デプロイできなかったパイプライン。

Feature Flags のポリシーは、フラグが更新されたり、オン/オフが切り替わったりしたときに適用され、標準の遵守、フラグプロセス、衛生に関するポリシーが可能になります。これには、以下のようなものがあります。

  • ブーリアン・フラグの作成のみを許可する。
  • フラグの命名規則を強制する
  • フラグを作成する際、デフォルトのオンとオフの値を両方ともfalseにすることを強制する。
  • QAでフラグを有効にした後、Productionでフラグを有効にできるようにする。

Policy as Code は、ソフトウェア開発におけるポリシー管理を一元化・標準化します。これにより、エンジニアリングリーダーは、開発チームが自分たちのツールやプラクティスを管理できるようにするとともに、全員がコンプライアンスとセキュリティに関する社内標準に従っていることを確認することができます。ガードレールが整備されていれば、開発チームがパイプラインを記述している間にセキュリティの脆弱性が生じることはありません。リーダーは、ポリシーと失敗を完全に監査できるため、コンプライアンス標準が満たされていることに安心し、シフトレフトガバナンスによって違反を早期に発見し報告することができます。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

Harnessに関するお問い合わせはお気軽にお寄せください。

お問い合わせ