Harness（ハーネス）は、ファイアウォールで保護されたシステムと機密データに関する企業共通の課題に対処するため、ローカルのKubernetesインフラストラクチャー上でOpen Policy Agent（OPA）評価を実行できる機能を導入したと発表した。この機能は、顧客の信頼境界内でポリシー・アズ・コードのチェックを実行しつつ、一元化された配信制御プレーンを維持することを目的としている。
今回の発表では、AIによるコード生成などが原因でエンジニアリング業務の負荷が増大し、デリバリーパイプラインへの負担が増大していることへの対応として、今回の変更が位置付けられた。OPAはパイプライン内のガバナンスを自動化するために使用されてきたが、そのデフォルトのクラウドベースの評価モデルは、大規模な規制対象組織における厳格なデータ所在地の要件やファイアウォールの要件と矛盾していた。
発表によると、ローカル評価の需要を高めた主なアーキテクチャー上の課題は2つある。1つは、チケット発行プラットフォームや独自スキャナーなど、受信側で保護された社内システムに問い合わせる必要性、もう1つは、APIトークン、証明書、パスワードを社内ネットワーク内に保持する必要があることだ。この新しいアプローチは、これまでチームがファイアウォールのポートを開放したり、インフラストラクチャーを複製したり、手動チェックに戻したりせざるを得なかったトレードオフを回避するものだと説明されている。
この製品は、Harness control planeから顧客のKubernetesクラスターへ評価意図を送信し、そこでOPAエンジンが実行される。評価結果は合格か不合格かの単純な形で報告され、機密情報や機密性の高いペイロードはローカル環境に保持され、プライベートツールは直接照会される。Harnessはこの製品を、統合SaaSプラットフォームのスケーラビリティーと管理上のメリットに加え、ローカル実行のセキュリティーを提供するものとして位置付けている。
実際の使用例がいくつか紹介された。1つは免除または例外に関するもので、テストカバレッジが95%以上などのしきい値を適用するポリシーは、内部チケットワークフローが例外を承認し、ServiceNowやJIRAなどのシステムに記録すれば、文書化された1回限りのホットフィックスに対してはバイパスできる。もう1つの使用例はパイプラインの改ざんチェックに関するもので、内部データベースに保存されている承認済みパイプラインのハッシュをローカルで実行されているregoポリシーと比較することで、実行中のYAMLが変更されていないことを確認できる。3つ目のシナリオは、顧客が外部ポリシーサービスに送信したくない非常に大きなペイロードや機密性の高いペイロードに関するものだ。
同社は、開発者の日常業務に変化はない一方、プラットフォームおよびセキュリティー責任者は、各評価に関する包括的な監査証跡を取得できるため、コンプライアンスレビューが簡素化されると述べている。ローカルOPA評価を処理するようにKubernetesクラスターを構成する方法を示すデモ動画も公開された。
出典：Harness
この製品の詳細については、Harness製品ページをご覧ください。
