CodeMeterのKubernetes対応

Kubernetesの概要

Kubernetesは、コンテナの統合・管理を行う強力なオープンソースプラットフォームであり、分散環境でのアプリケーションの展開・管理を容易にするために開発されました。

もともとKubernetesはGoogleで誕生し、その後2014年にオープンソースとしてリリースされました。Kubernetesは、DevOps（開発と運用）とコンテナ化に革新をもたらしたと言ってもよいでしょう。

Kubernetesでは、コンテナアプリケーションをPodと呼ばれるグループにまとめることができます。Podは、インフラ（例：クラウド、ローカルデータセンター）上で使用することが可能です。このようなPodを用いることでKubernetesは、自動スケーリング、ロードバランシング（負荷分散）、ローリングアップデート、ロールバック（後退復帰）を備え、柔軟性、耐障害性（フォールトトレランス）、高可用性が実現されています。

さらに、自己回復機能によるレジリエンスも備えており、アプリケーションの安定した動作が確保されています。このようにKubernetesは、最新のアプリケーションアーキテクチャーに可搬性と持続可能性をもたらし、世界中に存在する多様なアプリケーションの効率的な管理に欠かせないツールとなっています。

保護とライセンシング

分散環境では他の環境以上に、知的財産（IP）保護やライセンシングに気を配る必要があります。そこでWibu-Systemsでは、保護されたアプリケーションをKubernetesで安全に運用できるよう、CodeMeter Protection SuiteとAxProtectorを提供しています。

では、Kubernetesで、必要なCodeMeterライセンスをどのように提供すればよいのでしょうか？Kubernetesには、それぞれ異なる機能やマイクロサービスを備えたコンテナが多数存在します。CodeMeterを使用するには、まずCodeMeterライセンスサーバーが必要です。但し、そのライセンスサーバーは通常、保護とライセンシングが施されたサービスやアプリケーションとは別のコンテナに配置されます。

従ってアプリケーションコンテナが、別のコンテナにあるCodeMeterライセンスサーバーにアクセスするには、変数CODEMETER_HOSTを適切に設定し、専用のネットワークを構築しなければなりません（詳細はKEYnote 42を参照ください）。

CodeMeterライセンスサーバーとライセンスの確認

独自のKubernetesクラスターを設計する場合には、適切なライセンシングプロセスを踏むよう特に注意を払う必要があります。大規模なプロジェクトであれば、複数のCodeMeterライセンスサーバーを同時に稼働させなければなりません。場合によっては、Podごとに1つずつ稼働させるという手もあります。冗長性、パフォーマンス、利用可能なリソースなど、様々な要素を考慮して、最適な設計を行うべきです。

またCodeMeterライセンスサーバーだけでなく、ライセンス自体も利用可能であるか確認が必要です。ライセンスは、CmDongle（ハードウェアベース）、CmActLicense（ソフトウェアベース）、CmCloudContainer（クラウドベース）、これら3つのいずれかの形式でCmContainerに保管されます。これらのCmContainerタイプはすべて、ユニバーサルファームコードに対して暗号化処理上、同一であるため、それぞれのケースに応じて選択することができます。そこで、Kubernetesに適したCmContainerタイプは、どれかという疑問が湧くかと思いますが、Kubernetesをどこでどのように使用するかによって、それに対する答えは変わってきます。

最適なCmContainerタイプ：クラウドの場合

主要なクラウドプロバイダーであるAWS、Microsoft Azure、Google Cloudを利用する場合、Kubernetes経由でサービスを管理するための方法（ローカルシステムと同様にクラウド上で簡単にシステムを構築できる手段も含む）が幅広く提供されています。このようにインターネットへの常時接続があるクラウド上でコンテナを実行する場合、CmCloudContainerをおすすめします。Wibu-Systemsは、高可用性を確保したプライベートクラウドでCmCloudContainerを運用しています。また、鍵はすべてプライベートクラウド内で安全に保管され、暗号化処理もその中で行われます。さらに、ライセンスはCodeMeter License Portalを利用して、簡単にアクティベートすることができます。従って、CodeMeterライセンスサーバーに必要となるものは、画像形式で提供される、CmCloudContainerへの詳細なアクセス情報のみです。サービスは、「シート」という単位の同時ライセンスアクセス数に応じて課金されます。

最適なCmContainerタイプ：オンサイトの場合

社内でKubernetesをインストールする場合、CmCloudContainerを使用することで、前述のメリットを受けることはもちろん可能です。但しこれには、インターネットへの常時接続が必須条件になります。そこで、オフラインになる可能性がある、または他社インフラへの依存を避けたいユーザー向けには、CmDongleもしくはCmActLicenseをおすすめします。

ソフトウェア開発者の多くは、外部システムに依存することなく、Kubernetesに対応した形でソフトウェアとライセンスを提供したいと考えているのではないでしょうか。これは、コンテナ環境のすべてを自身（自社）で管理し、Kubernetesの利便性を損なわせる複雑な要件を無くしたい、という開発者の思いから来ていると想像できます。

模倣品の製造を防ぐためCmActLicenseでは、暗号化かつ適切なバインドが成された、不正コピーを防止する一意のアンカーを使用します。なぜアンカーが必要なのでしょうか。コンテナ環境は、その性質上、すべてが可能な限り抽象化され、システム間で簡単に切り替えられるよう設計されています。その結果、必要なアンカーを探し出すことが困難です。Wibu-Systemsは、すでにDocker向けの革新的なソリューションを提供しています（詳細はKEYnote 42をご参照ください）が、このメカニズムは、Docker固有のものであり、Kubernetesでは使用することが不可能です。さらに、ライセンスをハードウェアドライブのシリアル番号などにバインドするような従来のバインド方法も、簡単に模倣できてしまいます。また、Kubernetes、特にその基本的となるコンテナ化技術は、オープンになっているため、メカニズムの分析・模倣・回避が簡単にできてしまいます。従って、KubernetesにおいてCmActLicenseは、セキュリティ上問題があることは否めず、セキュアな環境を求める場合には不適切です。

一方で、Kubernetesの外部でライセンシングを行うという方法もあります。1つ以上のCodeMeterライセンスサーバーは、コンテナとして提供することも可能です。これらは、物理システム（コンテナではなく、かつ仮想マシンでもないことが理想）上に保管されているCodeMeterライセンスサーバーと接続することができます。これにより、特許取得技術であるSmartBindを搭載したCodeMeterを使用し、物理システムのプロパティがもつフィンガープリントへのライセンスのバインドが可能になります。

さらに、ネットワーク上のCodeMeterライセンスサーバーは、Kubernetes内でCmDongleに保存されたライセンスへのアクセスにも使用することもできます。これには、USB-over-Ethernet経由でCmDongleに接続する方法が一般的とされています。SEH DongleServerのようなデバイスにより、KubernetesのコンテナからTCP/IP経由でCmDongleへのアクセスが可能になります。このソリューションは、接続を再度設定し直すだけでよいため、コンテナが停止している場合でも可能であるというメリットがあります。

また、オペレーティングシステム（OS）のメンテナンス中であっても、TMRサーバーを統合することで、ローカルライセンスの高可用性を実現することが可能です。詳細は、TMRサーバーに関するKEYnoteをご参照ください。

もう一つのライセンシング方法

CodeMeterのライセンスは、クラウドまたは物理システム上にあるCodeMeterライセンスサーバーを通じて提供することで、Kubernetesの外部に統合することもできます。これにより、ライセンシングの安全性と信頼性が担保されます。このように、Kubernetes上でのアプリケーションの高可用性、IP保護の実現、そしてライセンス条項の実施には、目的に沿った慎重なライセンシング計画と適切な配布方法の選択が重要です。

-------------------------------------------------------------------------------------------------------

Open Industry 4.0コミュニティ推奨のプラットフォーム

Hilscherと私たちWibu-Systemsは、Open Industry 4.0（OI4）コミュニティの他の主要メンバーと共に、Flagship Store for the OI4 communityとされるオープンプラットフォームを開発しています。この取り組みは、「統合」「デジタル化」「相互接続」「安全性」、これらすべてが揃った生産環境を目指しています。また、生産性の課題やスキル不足に悩む現場のアプリユーザーから、デジタル生産部門へのセキュアかつ円滑な参入を強く求めるアプリ提供者に至る、すべての人へ恩恵をもたらすことを目的としています。そして、Hilscherと弊社のパートナーシップにより、ソフトウェアソリューションに組み込まれたIPの強力な保護を実現することが何よりも重要です。

KEYnote 46 – Edition Fall/Winter 2023

ソリューション

製品

ユーザー実績

サービス

サポート＆ダウンロード

リソース

パートナー

会社情報