変更しなければならないKubernetesのセキュリティ

　セキュリティは大きな問題の一つだ。オンプレミスを中心に考えてきた顧客はセキュリティが厳密に管理されることを望んでいる。だが同等のセキュリティはコンテナでは実現できない。こうした昔ながらの考えを持つ顧客には異なるアプローチが必要だ。そうした顧客が慣れているセキュリティはKubernetesに組み込まれていない。

　セキュリティの管理をクラウドネイティブ環境の範囲から外すべきだと提案しているわけではない。クラウドネイティブの考え方とオンプレミスの考え方の中間を取る必要がある。つまり、イメージとプラクティスの検証済みのセットを用意する。これを利用して企業全体のセキュリティを標準化する。

　この標準化は社内で設計する次善のセキュリティプラクティスのセットだが、エンジニアリング部門の共感は得られないだろう。セキュリティエンジニアの多くはKubernetesを理解していない。コンテナ内で使うJavaのバージョンや既に備えができている脆弱（ぜいじゃく）性の数やその深刻度のようなものをKubernetesに適用するのがどれほど難しいかを理解していない。

コンプライアンス、しかも「as code」型のコンプライアンス

　これは予想というよりも夢だ。だが、これが実現するのを見てみたい。コンテナ化とKubernetesから業務上のメリットを引き出すには、企業独自のプロセスを変える必要がある。開発者はKubernetesを利用することで、リアルタイムの運用と継続的デリバリー（CD）のサポートが可能になる。だが変更諮問委員会を擁する銀行のような組織のプロセスはCDには向いていない。

　理想は、自動化された変更諮問委員会、つまりCompliance As Codeの実現だ。エンジニアがコードを作成しているときに、それがコンプライアンスに従っているかどうかやセキュリティが確保されているかどうかを確認する。こうした確認をリリースの数日前の土壇場で行うのではない。つまりセキュリティをプロセスの前半に移す。それが時間を短縮し、問題を減らすことにつながる。最終段階での緊張の多いチェックは毎日の定型業務になる恐れがあるためだ。

　現実の問題は、この種の変化を企業が受け入れるかどうかだ。多くの企業はこの種の変化に消極的だ。外部の専門家を招き、こうした変化を促すことが非常に重要になる。外部の専門家は変化の方向へと企業を導き、課題に対処するための全く新たな方法を企業が思い描くのを支援できる。

　オンラインバンキングサービスを例に取ると、銀行の取引明細書が画面に表示されるレイアウトさえ、預金通帳をハードコピーしたデジタル版にすぎないのは明らかだ。銀行がデジタル化を試みたとき銀行が最初にしたことは、銀行自体が既に知っていることをデジタル化することだった。その後、Revolutのような真のディスラプターが登場し、顧客にほとんど費用を負担させることなくユーザーインタフェースだけでなくオンラインバンキングの可能性についての全体的なエクスペリエンスの考え方を変えた。

　実際、これが企業ITに広がっている病である「コンウェイの法則」だ。つまり現在の通信チャネルを新たに考案するのではなく、そのチャネルを模倣するようにITシステムをモデル化している。

相互の糧となるKubernetesとデジタル変革

　変革を望む企業は、Kubernetesのような最新のツールで社内機能を構築することから始める。同時に自社が抱えるより大きな課題について社外専門家の協力を仰ぐ。デジタル変革プログラムを実施しているなら、デリバリーパイプラインを標準化する絶好の機会だ。「ベストプラクティス」としていることは本当のベストプラクティスなのか、それは認定を受けた国際的な専門家が設定したものか、それは「自社でしか機能しない」恣意（しい）的な規則を設定したものではないのかを確認する。セキュリティ制御に合格してもおらず、どのような標準にも準拠していない航空機を想像できるだろうか。そんなものはないだろう。だが、航空機が使うソフトウェアはこのような問題に苦しんでいるかもしれない。

　Kubernetesは単なるツールであることを忘れてはならない。企業がプロセスを変えなければツールは正しく機能しない。

標準化と承認印

　最後に指摘しておきたい点は、Kubernetesにもかなりの標準化が必要な点だ。機能の重複がKubernetesエコシステムをいら立たせ、問題になり始めている。多くのサードパーティーコンポーネントが同じ機能を実行するとしたら、企業は自社のニーズに最適なコンポーネントをどのように判断できるだろう。コンセンサスや公式の評価プロセスがなければ開発者は推測するしかなく、誤った推測を行いかねない。Kubernetesの標準化はまだ行われていない。だがコミュニティーにとっては標準化が真のメリットになる。

　企業がある種の承認印を押すことを期待している。Kubernetesのコンポーネントが目的に適しており、最低限のパフォーマンスと機能を実現することを認める承認印だ。これはオープンソースコミュニティーにとって大きなメリットになる。同じことがJavaに起きた。現在ではApache Software FoundationのソフトウェアかSpring Frameworkに価値があり、高品質だという評価が高い。標準化と品質マークは成熟のサインだ。Kubernetesもこの方向に進む必要があり、この方向に進む価値がある。

デビッド・ゴンザレス氏はNearFormでDevOpsのデリバリーアーキテクトを務めている。同氏はKubernetesにおけるGoogle Developer Expertで、JavaScript、マイクロサービス、DevOpsに関する書籍を3冊執筆している。CCT College Dublinで「Cloud and Distributed Systems」の非常勤講師も務めている。同氏の使命は企業のITプロセスと文化を変革し、技術を企業の負担ではなく成功要因にすることだ。