特許 7705205 コンピューティング・クラスタのバージョン管理構成内のアクセス制御のための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-07-01

(45)【発行日】2025-07-09

(54)【発明の名称】コンピューティング・クラスタのバージョン管理構成内のアクセス制御のための方法およびシステム

(51)【国際特許分類】

   G06F 8/71 20180101AFI20250702BHJP

   G06F 8/65 20180101ALI20250702BHJP

【ＦＩ】

G06F8/71

G06F8/65

【請求項の数】 20

(21)【出願番号】P 2023521425

(86)(22)【出願日】2021-10-06

(65)【公表番号】

(43)【公表日】2023-11-01

(86)【国際出願番号】 IB2021059148

(87)【国際公開番号】W WO2022090839

(87)【国際公開日】2022-05-05

【審査請求日】2024-03-07

(31)【優先権主張番号】17/079,531

(32)【優先日】2020-10-26

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(74)【代理人】

【識別番号】100120710

【弁理士】

【氏名又は名称】片岡 忠彦

(72)【発明者】

【氏名】レフ、ラン、エタイ

(72)【発明者】

【氏名】ロイトマン、アレクセイ

(72)【発明者】

【氏名】カハナ、ツヴィ

(72)【発明者】

【氏名】ザック、イダン

(72)【発明者】

【氏名】マルカ、マイケル

(72)【発明者】

【氏名】ボートニコフ、ヴィータ

【審査官】円子 英紀

(56)【参考文献】

【文献】特開２０２０－１３５１５４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１９／０２４３９７９（ＵＳ，Ａ１）

【文献】会澤 康二，Ｋｕｂｅｒｎｅｔｅｓ ｏｎ ＡＷＳ，第1版，株式会社リックテレコム，2020年03月25日，p.24-25, 249-281

【文献】須田 一輝，Ｋｕｂｅｒｎｅｔｅｓ実践入門，第1版，株式会社技術評論社，2019年03月16日，p.62, 184-201

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／６０－８／７７

(57)【特許請求の範囲】

【請求項1】

構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法であって、前記方法は、プロセッサによって、
前記コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別することと、
前記少なくとも１つの変更を実行するためのユーザの識別情報を前記構成管理システムのリポジトリから取り出すことと、
前記オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得することであって、前記クエリが前記ユーザの前記識別情報を使用して前記少なくとも１つのファイルを変更する権限に関する、前記取得することと、
前記承認応答に応答して、認可互換性を前記チェックすることが承認されていることを確認するために、前記構成管理システムに前記承認応答を入力することと、
受信された前記拒絶に応答して、前記構成管理システムにメッセージを送信することであって、認可互換性を前記チェックすることが承認されていないことを前記メッセージが示す、前記送信することと
を含む、方法。

【請求項2】

前記プロセッサによって、前記少なくとも１つの変更されたファイルを分析して、前記変更によって影響を受けたオブジェクトおよび動作を検出することと、
前記プロセッサによって、前記オーケストレーション・システムにアクセスして、前記取り出されたユーザ識別情報が前記オーケストレーション・システム内の前記変更を実行すること、ならびに前記実行された変更によって影響を受けた前記オブジェクトおよび動作を適用することを認可されていることを検証することにより、前記オーケストレーション・システムに対する認可互換性をチェックすることと
をさらに含む、請求項１に記載の方法。

【請求項3】

前記プロセッサによって、前記構成管理システムと前記コンピューティング・クラスタの前記オーケストレーション・システムとの間の認可互換性をチェックするために、前記構成管理システムのユーザ名と前記コンピューティング・クラスタの前記オーケストレーション・システムのユーザ名との間をマッピングすること
をさらに含む、請求項１に記載の方法。

【請求項4】

前記構成管理システムがバージョニング管理システムである、請求項１に記載の方法。

【請求項5】

前記構成管理システムがＧｉｔである、請求項４に記載の方法。

【請求項6】

前記コンピューティング・クラスタの前記オーケストレーション・システムがＫｕｂｅｒｎｅｔｅｓである、請求項１に記載の方法。

【請求項7】

前記構成管理システムが前記コンピューティング・クラスタの一部である、請求項１に記載の方法。

【請求項8】

受信された前記拒絶に応答して、前記構成管理システムにメッセージを送信することが、以下の
前記少なくとも１つの変更が承認されていないことをユーザ・インターフェースによって前記ユーザに通知すること、
認可チェック互換性と一致するコメントもしくは変更要求で前記変更を承認する前記要求に返答すること、または
結果ファイルを追加すること
のうちの１つを含む、請求項１に記載の方法。

【請求項9】

前記ユーザが前記少なくとも１つの変更を実行するための前記コンピューティング・クラスタの前記オーケストレーション・システムから受信された承認に応答して、前記コンピューティング・クラスタに前記少なくとも１つの変更を適用すること
をさらに含む、請求項１に記載の方法。

【請求項10】

前記少なくとも１つのファイル内の前記少なくとも１つの変更を承認する前記要求を識別することが、前記構成管理システムの変更審査フローの間に行われる、請求項１に記載の方法。

【請求項11】

前記少なくとも１つのファイルにおいて複数の変更を実行する権限に関して、クエリが前記オーケストレーション・システムに供給され、前記変更の一部が承認され、前記変更の一部が拒絶されているときに、前記コンピューティング・クラスタに前記承認されている変更の一部を適用し、拒絶されている変更の前記一部についてユーザ・インターフェースによって前記ユーザに通知する、請求項１に記載の方法。

【請求項12】

構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法を実行する少なくとも１つのプロセッサを有するサーバであって、
前記コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別することと、
前記少なくとも１つの変更を実行するためのユーザの識別情報を前記構成管理システムのリポジトリから取り出すことと、
前記オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得することであって、前記クエリが前記ユーザの前記識別情報を使用して前記少なくとも１つのファイルを変更する権限に関する、前記取得することと、
前記承認応答に応答して、認可互換性を前記チェックすることが承認されていることを確認するために、前記構成管理システムに前記承認応答を入力することと、
受信された前記拒絶に応答して、前記構成管理システムにメッセージを送信することであって、認可互換性を前記チェックすることが承認されていないことを前記メッセージが示す、前記送信することと
を行うように構成される、サーバ。

【請求項13】

前記少なくとも１つの変更されたファイルを分析して、前記変更によって影響を受けたオブジェクトおよび動作を検出することと、
前記オーケストレーション・システムにアクセスして、前記取り出されたユーザ識別情報が前記オーケストレーション・システム内の前記変更を実行すること、ならびに前記実行された変更によって影響を受けた前記オブジェクトおよび動作を適用することを認可されていることを検証することにより、前記オーケストレーション・システムに対する認可互換性をチェックすることと
を行うようにさらに構成される、請求項１２に記載のサーバ。

【請求項14】

前記構成管理システムと前記コンピューティング・クラスタの前記オーケストレーション・システムとの間の認可互換性をチェックするために、前記構成管理システムのユーザ名と前記コンピューティング・クラスタの前記オーケストレーション・システムのユーザ名との間をマッピングすること
を行うようにさらに構成される、請求項１２に記載のサーバ。

【請求項15】

構成管理システムの一部として、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための前記方法を実行する、請求項１２に記載のサーバ。

【請求項16】

連続統合連続展開（ＣＩＣＤ）システムの一部として、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための前記方法を実行する、請求項１２に記載のサーバ。

【請求項17】

コンピューティング・クラスタの一部として、構成管理システムと前記コンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための前記方法を実行する、請求項１２に記載のサーバ。

【請求項18】

構成管理システムとオーケストレーション・システムとの間の認可互換性をチェックするためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、
コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別するプログラム命令と、
前記少なくとも１つの変更を実行するためのユーザの識別情報を前記構成管理システムのリポジトリから取り出すプログラム命令と、
前記オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得するプログラム命令であって、前記クエリが前記ユーザの前記識別情報を使用して前記少なくとも１つのファイルを変更する権限に関する、前記プログラム命令と、
前記承認応答に応答して、認可互換性を前記チェックすることが承認されていることを確認するために、前記構成管理システムに前記承認応答を入力するプログラム命令と、
受信された前記拒絶に応答して、前記構成管理システムにメッセージを送信するプログラム命令であって、認可互換性を前記チェックすることが承認されていないことを前記メッセージが示す、前記プログラム命令と
を含む、コンピュータ・プログラム。

【請求項19】

前記少なくとも１つの変更されたファイルを分析して、前記変更によって影響を受けたオブジェクトおよび動作を検出するプログラム命令と、
前記オーケストレーション・システムにアクセスして、前記取り出されたユーザ識別情報が前記オーケストレーション・システム内の前記変更を実行すること、ならびに前記実行された変更によって影響を受けた前記オブジェクトおよび動作を適用することを認可されていることを検証することにより、前記オーケストレーション・システムに対する認可互換性をチェックするプログラム命令と
をさらに含む、請求項１８に記載のコンピュータ・プログラム。

【請求項20】

前記構成管理システムと前記コンピューティング・クラスタの前記オーケストレーション・システムとの間の認可互換性をチェックするために、前記構成管理システムのユーザ名と前記コンピューティング・クラスタの前記オーケストレーション・システムのユーザ名との間をマッピングするプログラム命令
をさらに含む、請求項１８に記載のコンピュータ・プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、そのいくつかの実施形態では、コンピューティング・クラスタのオーケストレーション・システムのバージョン管理構成のアクセス制御に関し、より詳細には、排他的ではないが、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法およびシステムに関する。

【背景技術】

【0002】

コンテナ技術は、依存関係が分離した状態で動作するようにアプリケーションをパッケージ化することに基づく。コンテナは、コンピュータ・システムのコンテナのコンパートメント化に起因して、今日のソフトウェアの開発を根本的に変更している。

【0003】

コンテナは、論理的なパッケージ化メカニズムを提供し、その中で、アプリケーションはそれらが実際に動作するターゲット環境から取り除かれる場合がある。この分離により、ターゲット環境が専用データ・センタか、パブリック・クラウドか、さらには開発者の個人用ラップトップかにかかわらず、コンテナ・ベースのアプリケーションが容易にかつ一貫して開発されることが可能になる。開発者は自分のアプリケーションの論理および依存関係に焦点を当てるが、情報技術（ＩＴ）運用チームは、特定のソフトウェア・バージョンおよびアプリケーション（アプリ）に固有の構成などのアプリケーションの詳細に思い悩むことなく、アプリケーションの開発および管理に焦点を当てることができるので、コンテナ化は関心の明確な分離を実現する。

【0004】

コンテナにより、アプリケーションおよびその依存関係を一緒に、バージョン制御され得る１つの単位にパッケージ化することが可能になり、チームの開発者およびクラスタ内のマシンにわたるアプリケーションの容易な複製が可能になる。

【0005】

サービス・ベースのアーキテクチャと組み合わされて、開発者が論証するように求められる全体的な単位はより一層小さくなり、機敏性および生産性がより大きくなる。このすべてにより、アプリケーションの開発、テスト、展開、および総合的な管理が容易になる。

【0006】

コンテナ・オーケストレーションは、特に（複合クラウド環境などの）大きく動的な環境内のコンテナのライフサイクルを管理する管理システムである。

【0007】

（バージョン制御システムとも呼ばれる）バージョニング管理システムは、ソフトウェア・チームがソース・コードに対する変更を経時的に管理するのを助けるソフトウェア・ツールのカテゴリである。バージョン制御ソフトウェアは、コードに対するあらゆる修正を独特のデータベース内に記録する。開発間違いが行われた場合、開発者は、すべてのチーム・メンバに対する混乱を最小限に抑えながら、後戻りし、前のバージョンのコードと比較して間違いを直すのを助けることができる。

【発明の概要】

【0008】

本開示の目的は、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするためのシステムおよび方法を説明することである。

【0009】

上記および他の目的は、独立請求項の機能によって実現される。さらなる実装形態は、従属請求項、説明、および図から明らかである。

【0010】

１つの態様では、本開示は、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法に関する。本方法は、
コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別することと、
少なくとも１つの変更を実行するためのユーザの識別情報を構成管理システムのリポジトリから取り出すことと、
オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得することであって、クエリがユーザの識別情報を使用して少なくとも１つのファイルを変更する権限に関する、取得することと、
承認応答に応答して、認可互換性をチェックすることが承認されていることを確認するために、構成管理システムに承認応答を入力することと、
受信された拒絶に応答して、構成管理システムにメッセージを送信することであって、認可互換性をチェックすることが承認されていないことをメッセージが示す、送信することと
を含む。

【0011】

第１の態様のさらなる実装形態では、本方法は、
少なくとも１つの変更されたファイルを分析して、変更によって影響を受けたオブジェクトおよび動作を検出することと、
オーケストレーション・システムにアクセスして、取り出されたユーザ識別情報がオーケストレーション・システム内の変更を実行すること、ならびに実行された変更によって影響を受けたオブジェクトおよび動作を適用することを認可されていることを検証することにより、オーケストレーション・システムに対する認可互換性をチェックすることと
をさらに含む。

【0012】

第１の態様のさらなる実装形態では、本方法は、
構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするために、構成管理システムのユーザ名とコンピューティング・クラスタのオーケストレーション・システムのユーザ名との間をマッピングすること
をさらに含む。

【0013】

第１の態様のさらなる実装形態では、構成管理システムはバージョニング管理システムである。

【0014】

第１の態様のさらなる実装形態では、構成管理システムはＧｉｔである。

【0015】

第１の態様のさらなる実装形態では、コンピューティング・クラスタのオーケストレーション・システムはＫｕｂｅｒｎｅｔｅｓである。

【0016】

第１の態様のさらなる実装形態では、構成管理システムはコンピューティング・クラスタの一部である。

【0017】

第１の態様のさらなる実装形態では、受信された拒絶に応答して、構成管理システムにメッセージを送信することは、以下の
少なくとも１つの変更が承認されていないことをユーザ・インターフェースによってユーザに通知すること、
認可チェック互換性と一致するコメントもしくは変更要求で変更を承認する要求に返答すること、または
結果ファイルを追加すること
のうちの１つを含む。

【0018】

第１の態様のさらなる実装形態では、本方法は、
ユーザが少なくとも１つの変更を実行するためのコンピューティング・クラスタのオーケストレーション・システムから受信された承認に応答して、コンピューティング・クラスタに少なくとも１つの変更を適用すること
をさらに含む。

【0019】

第１の態様のさらなる実装形態では、少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別することは、構成管理システムの変更審査フローの間に行われる。

【0020】

第１の態様のさらなる実装形態では、少なくとも１つのファイルにおいて複数の変更を実行する権限に関して、クエリがオーケストレーション・システムに供給され、変更の一部が承認され、変更の一部が拒絶されているときに、コンピューティング・クラスタに承認されている変更の一部を適用し、拒絶されている変更の一部についてユーザ・インターフェースによってユーザに通知すること。

【0021】

第２の態様では、本開示は、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法を実行する少なくとも１つのプロセッサを有するサーバに関し、本サーバは、
コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別することと、
少なくとも１つの変更を実行するためのユーザの識別情報を構成管理システムのリポジトリから取り出すことと、
オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得することであって、クエリがユーザの識別情報を使用して少なくとも１つのファイルを変更する権限に関する、取得することと、
承認応答に応答して、認可互換性をチェックすることが承認されていることを確認するために、構成管理システムに承認応答を入力することと、
受信された拒絶に応答して、構成管理システムにメッセージを送信することであって、認可互換性をチェックすることが承認されていないことをメッセージが示す、送信することと
を行うように構成される。

【0022】

第２の態様のさらなる実装形態では、本サーバは、
少なくとも１つの変更されたファイルを分析して、変更によって影響を受けたオブジェクトおよび動作を検出することと、
オーケストレーション・システムにアクセスして、取り出されたユーザ識別情報がオーケストレーション・システム内の変更を実行すること、ならびに実行された変更によって影響を受けたオブジェクトおよび動作を適用することを認可されていることを検証することにより、オーケストレーション・システムに対する認可互換性をチェックすることと
を行うようにさらに構成される。

【0023】

第２の態様のさらなる実装形態では、本サーバは、
構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするために、構成管理システムのユーザ名とコンピューティング・クラスタのオーケストレーション・システムのユーザ名との間をマッピングすること
を行うようにさらに構成される。

【0024】

第２の態様のさらなる実装形態では、少なくとも１つのプロセッサは、構成管理システムの一部として、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法を実行する。

【0025】

第２の態様のさらなる実装形態では、少なくとも１つのプロセッサは、連続統合連続展開（ＣＩＣＤ：Ｃｏｎｔｉｎｕｏｕｓ Ｉｎｔｅｇｒａｔｉｏｎ Ｃｏｎｔｉｎｕｏｕｓ Ｄｅｐｌｏｙｍｅｎｔ）システムの一部として、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法を実行する。

【0026】

第２の態様のさらなる実装形態では、少なくとも１つのプロセッサは、コンピューティング・クラスタの一部として、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法を実行する。

【0027】

第３の態様では、本開示は、構成管理システムとオーケストレーション・システムとの間の認可互換性をチェックするためのコンピュータ・プログラム製品に関し、本コンピュータ・プログラム製品は、
１つまたは複数のコンピュータ可読記憶媒体、および１つまたは複数のコンピュータ可読記憶媒体に一括して記憶されたプログラム命令
を含み、プログラム命令は、
コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別するプログラム命令と、
少なくとも１つの変更を実行するためのユーザの識別情報を構成管理システムのリポジトリから取り出すプログラム命令と、
オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得するプログラム命令であって、クエリがユーザの識別情報を使用して少なくとも１つのファイルを変更する権限に関する、プログラム命令と、
承認応答に応答して、認可互換性をチェックすることが承認されていることを確認するために、構成管理システムに承認応答を入力するプログラム命令と、
受信された拒絶に応答して、構成管理システムにメッセージを送信するプログラム命令であって、認可互換性をチェックすることが承認されていないことをメッセージが示す、プログラム命令と
を含む。

【0028】

第３の態様のさらなる実装形態では、本コンピュータ・プログラム製品は、
少なくとも１つの変更されたファイルを分析して、変更によって影響を受けたオブジェクトおよび動作を検出するプログラム命令と、
オーケストレーション・システムにアクセスして、取り出されたユーザ識別情報がオーケストレーション・システム内の変更を実行すること、ならびに実行された変更によって影響を受けたオブジェクトおよび動作を適用することを認可されていることを検証することにより、オーケストレーション・システムに対する認可互換性をチェックするプログラム命令と
をさらに含む。

【0029】

第３の態様のさらなる実装形態では、本コンピュータ・プログラム製品は、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするために、構成管理システムのユーザ名とコンピューティング・クラスタのオーケストレーション・システムのユーザ名との間をマッピングするプログラミング命令をさらに含む。

【0030】

別段に規定されていない限り、本明細書で使用されるすべての技術用語または科学用語あるいはその両方は、本発明が関係する当業者によって通常理解されるものと同じ意味を有する。本明細書に記載されたものと同様または均等な方法および素材は、本発明の実施形態の実践または試験において使用することができるが、例示的な方法または素材あるいはその両方が以下に記載される。係争する場合、定義を含む特許明細書が統制することになる。加えて、素材、方法、および例は、例示的であるにすぎず、必ずしも限定するものではない。

【0031】

添付図面を参照して、ほんの一例として、本発明のいくつかの実施形態が本明細書に記載される。次に、図面を詳細に具体的に参照すると、示された詳細は、例として本発明の実施形態の例示的な説明のためである。この点に関連して、図面とともに取り込まれた説明は、本発明の実施形態がどのように実践され得るかを当業者に明らかにする。

【図面の簡単な説明】

【0032】

【図1】構成管理システムとオーケストレーション・システムとの間の対話を概略的に示す図である。

【図2】本開示のいくつかの実施形態による、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするためのシステムを概略的に示す図である。

【図3】本開示のいくつかの実施形態による、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするためのプロセスのフローチャートを概略的に示す図である。

【図4】本開示のいくつかの実施形態による、構成管理システムとしてのＧｉｔとオーケストレーション・システムとしてのＫｕｂｅｒｎｅｔｅｓとの間の認可をチェックするためのＧｉｔＯｐｓワークフローの一例を概略的に示す図である。

【発明を実施するための形態】

【0033】

本開示は、そのいくつかの実施形態では、コンピューティング・クラスタのオーケストレーション・システムのバージョン管理構成のアクセス制御に関し、より詳細には、排他的ではないが、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法およびシステムに関する。

【0034】

オーケストレーション・システムは、任意のパブリック・クラウドもしくはプライベート・クラウドまたはコンピューティング・クラスタ上で規模を拡大してコンテナを動作させるために重要である。オーケストレーション・システムにアプリケーションを展開し更新することは、アプリケーション・コードであるコンテナ画像を、展開構成、例えば、コンテナ画像を参照してＹＡＭＬファイル内の導出されたＰｏｄ定義と組み合わせる。セキュリティおよびコンプライアンスの観点から、コードと構成の両方の変更は、監査されバージョン管理されるべきである。

【0035】

構成管理システムは、企業が所有するすべてのソフトウェア資産およびハードウェア資産に対する任意の将来の変更が知られ追跡されるように、これらの資産がいつも知られ追跡されることを保証するためのシステムである。構成管理システムは、コンピュータ・システム、サーバ、およびソフトウェアを所望の均一な状態に維持し、それにより、経時的に変更が行われるにつれて予想されるようにシステムが実行することが確かになる。

【0036】

バージョニング管理システムまたはバージョン制御システムは、特定のバージョンが後で呼び出され得るように経時的にファイルまたは一組のファイルに対する変更を記録するシステムである。

【0037】

オーケストレーション・システム用の動作モデルは、クラウド・ネイティブ連続統合／連続展開（ＣＩ／ＣＤ）モデルである。このモデルは、バージョニング管理システムに基づき、展開環境に対するすべての変更および更新がバージョン制御への変更を介して発生するシステムである。そのような動作モデルは、自動的にアプリケーションおよび環境用のコードおよび構成を編成する一組の実践を提供する。手動で環境を構成する代わりに、すべての変更は、それらが承認され、新しいバージョンにマージされると自動的に展開される。オーケストレーション・システム用の動作モデルを有するバージョニング管理システムは、構成管理システムの実装形態のための一例である。

【0038】

構成管理システム、具体的にはバージョニング管理システムに基づくオーケストレーション・システム用の動作モデルにおける課題の１つはアクセス認可である。具体的には、構成管理システムおよびオーケストレーション・システムの認可は、調整もされず、互換性もない。違いは、３つの側面：チェックされるオブジェクト、認可チェックのタイプ、および認可チェックを実行する方法において表される。構成管理システムが管理するオブジェクトは、例えば、リポジトリおよびファイルに限定されるが、オーケストレーション・システムは、かなり広範囲に定義された任意のオブジェクトを管理する。この違いの一例は、構成管理システムの認可許諾およびオーケストレーション・システムの認可チェック・メカニズムとして定義されたアクセス認可において明確に表される。構成管理システムでは、アクセス認可は、少ないタイプのアクセス認可、例えば、読取り専用、読み書き、および管理者に限定されるが、オーケストレーション・システムは、列挙、読取り、書込み、削除、および更新などのきめの細かいタイプの認可チェック・メカニズムを有する。構成管理システムは、構成管理システムの一部として組み込まれた認可チェック・アクセス・メカニズムを備える、一方オーケストレーション・システムは、いくつかのアクセス認可メカニズムを含む。オーケストレーション・システムのアクセス認可メカニズムは、ユーザごと、オブジェクトごと、および動作ごとなどの多種多様のアクセス認可を可能にするモデルを定義する。

【0039】

この違いに起因して、オーケストレーション・システム用の構成またはバージョニングあるいはその両方の管理ベースの動作モデルのうちのいくつかは、構成またはバージョニングあるいはその両方の管理システムおよびオーケストレーション・システムから独立して、それら自体のアクセスモデルを定義する。このようにして、アクセス認可は、「ネイティブ」な構成またはバージョニングあるいはその両方の管理システムおよびオーケストレーション・システムのアクセス制御をバイパスして、動作モデルによって内部で管理される。これにより、オーケストレーション・システムのアクセス認可メカニズムが意味のないものになり、開発者または動作モデルに負担がかかる。

【0040】

オーケストレーション・システムのアクセス認可メカニズムが意味のないものになり、開発者に負担がかかることを回避するために、いくつかのバージョニング管理ベースの動作モデルは、オーケストレーション・システムからバージョニング管理フロー（例えば、コミットおよびマージ）を分離し、認可チェックから展開までの時間を遅らせることを決定した。これは、バージョニング管理システム内の承認されている変更が、認可を失うことに起因して潜在的に展開に失敗する可能性があるというマイナス面を有する。

【0041】

別の解決策は、動作モデルによって動作する単一の全能ユーザ・アカウントを使用して、すべての承認されている変更を可能にし、それらをオーケストレーション・システムに適用することであるが、これもオーケストレーション・システムのアクセス認可メカニズムを意味のないものにする。

【0042】

他の代替案は、例えば、バージョニング管理システムのユーザ・アクセス認可とオーケストレーションのアクセス認可との間をマッピングすることである。しかしながら、マッピングが単純な１対１のマッピングでない場合、これは機能しない。

【0043】

したがって、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための解決策を提供することが必要である。本開示は、オーケストレーション・システムのアクセス認可メカニズムを維持し、それを構成管理システムの変更審査フローに統合するシステムを記載する。本開示は、認可チェックが変更審査フローの一部として、かつオーケストレーション・システム内で定義された認可に対して行われるシステムおよび方法を記載する。変更審査フローは、コード・ファイルまたは構成ファイルあるいはその両方における変更が、ＣＩ／ＣＤテストを実行することによって自動的に、かつ他のユーザによってチェックされることによって両方でテストされ、変更がメイン・コード・ファイルにマージされる前に変更を審査して変更が正確であることを検証するプロセスである。このように、変更は、クラスタの状態および認可と互換性があることが保証される。認可チェックは、オーケストレーション・システムの全機能をサポートし、（例えば、オブジェクトのタイプ・アクセスごと、ユーザごと、および動作ごとなどの）認可メカニズムにアクセスし、多大な計算能力を必要とし、エミュレートされるシステムに関して不正確な可能性がある複雑なエミュレーションを必要としない。認可およびユーザは、構成オブジェクトを介してすべてが宣言的に管理されながら、ユーザおよび認可に対してもバージョン制御を実行することを可能にする単一の場所において維持される。

【0044】

本発明の少なくとも１つの実施形態を詳細に説明する前に、本発明は、以下の説明に記載され、かつ／あるいは図面もしくは例またはその両方に示された構成要素または方法あるいはその両方の構築および配置の詳細にその用途が必ずしも限定されないことが理解されるべきである。本発明は、他の実施形態、または様々な方法で実践もしくは遂行されることが可能である。

【0045】

本発明は、システム、方法、またはコンピュータ・プログラム製品あるいはその組合せであり得る。本コンピュータ・プログラム製品は、本発明の態様をプロセッサに実行させるためのコンピュータ可読プログラム命令をそれに有する、１つまたは複数のコンピュータ可読記憶媒体を含む場合がある。

【0046】

コンピュータ可読記憶媒体は、命令実行デバイスが使用するための命令を保持し記憶することができる有形デバイスであり得る。コンピュータ可読記憶媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、または前述の任意の適切な組合せであり得るが、それらに限定されない。

【0047】

本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれの計算／処理デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくはワイヤレス・ネットワークまたはその組合せを介して、外部コンピュータまたは外部ストレージ・デバイスにダウンロードすることができる。

【0048】

コンピュータ可読プログラム命令は、全体的にユーザのコンピュータもしくはコンピュータ化デバイスまたはその両方で、部分的にユーザのコンピュータもしくはコンピュータ化デバイスまたはその両方で、スタンドアロン・ソフトウェア・パッケージとして、部分的にユーザのコンピュータ（もしくはコンピュータ化デバイスまたはその両方）で、かつ部分的にリモート・コンピュータで、あるいは全体的にリモート・コンピュータまたはサーバで実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータもしくはコンピュータ化デバイスまたはその両方に接続されてもよく、あるいは接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部のコンピュータに対して行われてもよい。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路を個人向けにすることにより、コンピュータ可読プログラム命令を実行することができる。

【0049】

本発明の態様は、本発明の実施形態による、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して本明細書に記載されている。フローチャート図またはブロック図あるいはその両方の各ブロック、およびフローチャート図またはブロック図あるいはその両方のブロックの組合せは、コンピュータ可読プログラム命令によって実装できることが理解されよう。

【0050】

図の中のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示す。この点に関連して、フローチャートまたはブロック図内の各ブロックは、指定された論理機能を実現するための１つまたは複数の実行可能命令を含む命令のモジュール、セグメント、または部分を表すことができる。いくつかの代替の実装形態では、ブロック内で言及された機能は、図の中で言及された順序以外で行われてもよい。例えば、連続して示された２つのブロックは、実際には、関与する機能に応じて、実質的に並行して実行されてもよく、またはブロックは時々逆の順序で実行されてもよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、およびブロック図またはフローチャート図あるいはその両方内のブロックの組合せは、指定された機能もしくは行為を実行するか、または専用ハードウェアおよびコンピュータ命令の組合せを実行する専用ハードウェア・ベースのシステムによって実現できることにも留意されたい。

【0051】

次に図１に対して参照が行われ、図１は、構成管理システム１０１、および（オーケストレーション・システムとも呼ばれる）コンピューティング・クラスタのオーケストレーション・システム１０２との構成管理システムの対話を概略的に示す。構成管理システム１０１は、リポジトリ１０８に記憶された、コンピューティング・クラスタの構成を定義するコード・ファイル１０３を含む。コード・ファイル１０３は、（通常、マスタ・コードまたはマスタ・ブランチと呼ばれる）メイン・コードと、マスタ・コードのサブ・コードであるブランチ・コードとを含む。チームがコードに対して作業するとき、チーム内の各ユーザは、別個かつ別々にブランチ・コードに対して作業することができ、ブランチ・コードの準備ができた後に、ブランチ・コードはマスタ・コードにマージされる。マスタ・コードにブランチ・コードをマージする前に、ブランチ・コードは、誤りなく正確に動作することを確認するためにテストされ、別のユーザ（通常、管理者、経営者、シニア・エンジニア、または変更されたコードに詳しい誰かなど）が、ブランチ・コードが誤りなく適正であることをチェックする。ユーザがコード・ファイル１０３のうちの１つを修正するたびに、修正されたコード・ファイルは一度実行され、コンテナ１０４は、コード・ファイルが上等であることを検証する実行単位テストおよび統合テストのための連続統合（ＣＩ）プロセスの一部として構築される。コード・ファイルが実行に成功し、すべてのテストが承認された後に、構成ファイル１０５は変更されたコード・ファイルに従って更新され、変更されたコード・ファイルおよび変更された構成ファイルが他のユーザによって承認されると、ブランチ・コードであるコード・ファイルはマスタ・コードにマージされる。マスタ・コードが変更されると、オーケストレーション・システム１０２は、更新されたマスタ・コード用の更新された構成ファイルを実行するために、構成管理システム１０１によって更新される。

【0052】

次に図２に対しても参照が行われ、図２は、本開示のいくつかの実施形態による、構成システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするためのシステムを概略的に示す。構成システム２０１は認可チェック・エージェント２０７を含み、認可チェック・エージェント２０７は、少なくとも１つのプロセッサ２０９を有するサーバによって実行されるコードであり、コンピューティング・クラスタの構成を定義するコード・ファイル２０３または構成ファイル内でユーザによって行われた変更を識別する。例えば、ユーザが、コード・ファイル内のコード行を追加するか、コード行を削除するか、またはコード行を修正するとき。変更は、認可チェック・エージェント２０７により、例えば、変更に関する構成システムから通知を受信することによって識別される場合がある。認可チェック・エージェント２０７が、構成を定義したファイル内に変更があったことを識別すると、認可チェック・エージェント２０７は、ユーザの名前または識別情報およびユーザによって行われた変更によって影響を受けたファイルをリポジトリ２０８から取り出す。影響を受けたファイルおよびユーザの名前または識別情報が取り出された後に、認可チェック・エージェント２０７は、コンピューティング・クラスタのオーケストレーション・システム２０２に対して、オーケストレーション・システム２０２の認可アクセスに従ってファイル内の変更が取り出されたユーザ向けに認可されたかどうかを検証する。認可チェック・エージェント２０７は、コンピューティング・クラスタのオーケストレーション・システム２０２から承認応答または拒絶応答のいずれかを受信し、受信された応答に従って構成管理システムを更新する。認可チェック・エージェント２０７が承認応答を受信した場合、変更されたファイルはマスタ・ファイルにマージされ、構成管理システム２０１は、コンピューティング・クラスタのオーケストレーション・システム２０２へのマスタ・コードおよび構成の展開を続行する。認可チェック・エージェント２０７が拒絶応答を受信した場合、認可チェック・エージェント２０７は、認可チェック互換性が承認されていないことの通知を構成管理システム２０１に送信する。

【0053】

次に図３に対しても参照が行われ、図３は、本開示のいくつかの実施形態による、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法を記述するフローチャートである。

【0054】

３０１において、ユーザは、構成を定義したコード・ファイルまたは構成ファイルあるいはその両方の中で変更（例えば、コード行の追加、コード行の削除、またはコード行の修正）を行い、１つまたは複数のファイルを含む変更要求の形式で変更を提示する。提示された変更要求は変更審査フローを開始し、そこで、コード・ファイルおよび構成ファイル内の変更は、ＣＩ／ＣＤテストを実行することによって自動的に、かつ他のユーザによってチェックされることによって両方でテストされ、それは、変更を審査して変更が正確であることを検証する。３０２において、認可チェック・エージェント２０７は、例えば、提示された変更要求に関する構成管理システムからの通知を受信することにより、コンピューティング・クラスタの少なくとも１つのファイル内で提示された変更を承認する要求を識別する（例えば、認可チェック・エージェントは変更要求を識別する）。３０３において、認可チェック・エージェント２０７は、構成管理システム２０１のリポジトリ２０８から変更を実行するためのユーザの識別情報を取り出す。３０４において、認可チェック・エージェントは、ネットワークを介してオーケストレーション・システム２０２にクエリを送信し、クエリは、ユーザの識別情報を使用してオーケストレーション・システム２０２上のファイル内の変更（および変更によって影響を受けたファイル内の変更）を実行する権限を要求する。３０５において、認可チェック・エージェント２０７は、例えば、取り出されたユーザ識別情報に従ってファイル内の変更を実行するように要求するクエリが承認されているか拒絶されているかを知らせる通知を受信することにより、オーケストレーション・システムからクエリに対する拒絶応答または承認応答を取得する。３０６において、承認応答に応答して、認可チェック・エージェント２０７は、認可互換性をチェックすることが承認されていることを確認するために構成管理システム２０１に承認応答を入力する（例えば、構成管理システム２０１に承認を記録する）。３０７において、オーケストレーション・システム２０２から認可チェック・エージェント２０７によって受信された拒絶応答に応答して、取り出されたユーザ識別情報に従ってファイル内の変更を実行するために、認可チェック・エージェント２０７は構成管理システムにメッセージを送信し、メッセージは認可互換性をチェックすることが承認されていないことを示す。メッセージは、例えばユーザ・インターフェースに送信され、認可チェック互換性が承認されていないことを通知する場合があるか、またはメッセージは、ユーザ識別情報に対して（例えば、コード・ファイル内の行を追加もしくは削除するなどの）変更が承認されるために何の条件が必要とされるかを通知することができる。本開示のいくつかの実施形態によれば、認可チェック互換性は、構成管理システム２０１の変更審査フローの間に行われる。

【0055】

本開示のいくつかの実施形態によれば、認可チェック・エージェント２０７は、変更された一組のファイルを分析して、変更によって影響を受けた具体的なオブジェクトおよび動作を検出する。その上、認可チェック・エージェント２０７は、次いで、オーケストレーション・システムにアクセスして、取り出されたユーザがオーケストレーション・システム内の変更を実行すること、ならびに実行された変更によって影響を受けたオブジェクトおよび動作を適用することを認可されていることを検証することにより、オーケストレーション・システムに対する認可互換性をチェックする。

【0056】

本開示のいくつかの実施形態によれば、認可チェック・エージェント２０７は、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするために、構成管理システム２０１のユーザ名とオーケストレーション・システム２０２のユーザ名との間をマッピングする。より単純なケースでは、ユーザ名が直接マッピングされる。手動調整を介して、または、好ましくは外部認証メカニズム（例えば、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、オープンＩＤコネクト（ＯＩＤＣ））を使用して、構成管理システム２０１とオーケストレーション・システム２０２の両方のシステムにおいて同じユーザ名が使用される。より複雑なケースでは、認可チェック・エージェント２０７は、マッピング・ファイルを使用して、構成管理システム２０１のユーザ名からオーケストレーション・システム２０２のアクセス認可の適切な主導者へのマッピングを管理する。マッピング・ファイルはまた、構成管理システム２０１内で維持され、構成管理システム２０１の同様の審査および承認フローを受ける場合がある。マッピング・ファイルの場所は、リポジトリ２０８のために選ばれたディレクトリ編成に依存する場合がある（例えば、マッピング・ファイルは現在のディレクトリからロードされる）。

【0057】

本開示のいくつかの実施形態によれば、認可チェック・エージェントは、変更が承認されていないことをユーザ・インターフェースによってユーザに通知することにより、認可チェック互換性が確認されていないことを構成管理システムに通知する。あるいは、認可チェック互換性と一致するコメントもしくは変更要求で、変更を承認する要求（例えば、変更要求）に返答する。一方、ユーザが変更を実行するためにオーケストレーション・システム２０２から受信された承認に応答して、認可チェック・エージェント２０７は、コンピューティング・クラスタに変更を適用することができる。

【0058】

本開示のいくつかの実施形態によれば、構成管理システムとオーケストレーション・システムとの間の認可互換性をチェックするための一例は、構成管理システムがバージョニング管理システムおよびＧｉｔなどのオーケストレーション・システム用の動作モデルおよびＧｉｔＯｐｓワークフローによって実装され、オーケストレーション・システムがＫｕｂｅｒｎｅｔｅｓであるケースである。例えば、次に図４に対して参照が行われ、図４は、構成管理システムとしてのＧｉｔとコンピューティング・クラスタのオーケストレーション・システムとしてのＫｕｂｅｒｎｅｔｅｓとの間の認可互換性をチェックするための例示的なＧｉｔＯｐｓワークフローを概略的に示す。

【0059】

４０１において、ユーザは構成を定義するコード・ファイルまたは構成ファイルあるいはその両方の中で、コード・ファイル内の行の追加、行の削除、または行の修正などの変更を行い、１つまたは複数のファイルを含む（Ｇｉｔシステム用語でプル要求（ＰＲ）と呼ばれる）変更要求の形式で構成内の変更を提示する。４０２において、コンテナは、コード変更が上等であることを検証する実行単位テストおよび統合テストのための連続統合（ＣＩ）として構築され、４０３において、コンテナはコンテナ・レジストリに登録および格納される。本開示のいくつかの実施形態によれば、４０４において、認可チェック・エージェント４２０は、Ｇｉｔシステムによって認可チェック・エージェント４２０に送信された変更要求通知を受信することによってプル要求を識別する。認可チェック・エージェント４２０は、Ｇｉｔ構成管理システム４１０に位置するＧｉｔリポジトリから、変更をトリガしたユーザの識別情報および変更によって影響を受けたファイルを取り出す。Ｋｕｂｅｒｎｅｔｅｓはオブジェクトを管理するシステムなので、オブジェクトは適切なフォーマット（例えば、ＪＳＯＮ、ＹＡＭＬ）で符号化され、ファイルに格納されてもよい。認可チェック・エージェント４２０は、コード変更によって影響を受けたＫｕｂｅｒｎｅｔｅｓオブジェクトのリスト（例えば、オブジェクトの名前、タイプ、および名前空間（名前空間はクラスタを共有するユーザ間の論理的な分離を生み出す方法である））を抽出する。名前空間は、変更タイプ（例えば、行の削除、行の作成、行の修正）とともにファイルからのファイル・システム内のディレクトリ（異なるディレクトリにおいて同じファイル名を使用することが可能である）の役割と類似する。任意選択で、一度に異なる変更タイプの複数の変更が存在することができ、すべてが１つの変更セットに組み合わされる。認可チェック・エージェント４２０は、例えば、Ｇｉｔシステムのユーザ名とＫｕｂｅｒｎｅｔｅｓシステムのユーザ名の１：１マッピングにより、または変換テーブルを使用し、Ｇｉｔシステムのユーザ名をＫｕｂｅｒｎｅｔｅｓシステムのユーザ名に変換することにより、アクセスのチェックに使用されるようにＫｕｂｅｒｎｅｔｅｓのユーザ名を決定する。４０５において、認可チェック・エージェント４２０は、取り出されたユーザによる変更を実行する権限に関するクエリをＫｕｂｅｒｎｅｔｅｓシステムに送信する。クエリは、Ｋｕｂｅｒｎｅｔｅｓアプリケーション・プログラミング・インターフェース（ＡＰＩ）マスタを使用して（例えば、dry-run、can-i、およびユーザ偽装などのＫｕｂｅｒｎｅｔｅｓ動作を使用することによって）送信される場合がある。４０６において、認可チェック・エージェント４２０は、Ｋｕｂｅｒｎｅｔｅｓシステムから応答を受信し、プル要求に対する認可を報告し、プル要求を承認または拒絶する。４０７において、結局、認可チェック・エージェント４２０が認可チェック互換性のための承認を受信した後に、プル要求はマージされ、それは、ユーザによって行われた変更がマスタ・コード・ファイルおよび構成にマージされることを意味し、ＧｉｔＯｐｓツールがクラスタに変更セットをプルする、すなわち、変更がクラスタに適用される。

【0060】

本開示のいくつかの実施形態によれば、本明細書に記載された方法は、ターゲット・クラスタに対する認可チェックおよびそのポリシーを、Ｇｉｔ構成管理システム４１０の変更審査フロー内の変更のテストの一部として統合する。これにより、ＧｉｔＯｐｓツール内のユーザおよびアクセス管理機能を複製することなく、動作のためのＧｉｔベースのかつ直接のクラスタ・アクセスのための統合され一貫したアクセス制御が可能になる。認可チェック・エージェントなどの外部システムは、変更されたファイルの通知をＧｉｔに要求することができる。Ｇｉｔによって送信された通知情報は、ユーザによって要求された変更を識別するためにエージェントによって必要とされるすべての情報を含む。Ｇｉｔは、「コールバック」または「ウェブフック」（例えば、ＣｉｒｃｌｅＣＩツールまたはＴｒａｖｉｓツールに対するウェブフック）と呼ばれるプロセスを介して格納されたファイルに対する変更の外部ツーリングを通知することができる。別の例は、ＧｉｔＨｕｂ基盤上で様々なツーリングを実行するために使用することもできる「ＧｉｔＨｕｂアクション」である。両方のモードにおいて、呼出しは、コミット識別子、マージされるブランチなどの特定のコミットに関する必要な情報を含む。情報は、リポジトリにアクセスし、関連する変更セット（または必要な場合、ブランチ／プル要求全体）を取り出すのに十分である。

【0061】

コード・ファイル内および構成内で行われた変更の通知を受信すると、認可チェック・エージェント４２０は、影響を受けたファイルおよび変更を行ったユーザの識別情報をＧｉｔリポジトリから取り出す。変更を行ったユーザおよびこの変更によって影響を受けたファイルが知られると、認可チェック・エージェント４２０は、既存のＫｕｂｅｒｎｅｔｅｓ機能を使用して、変更されたファイルに含まれるオブジェクトが変更に関与したユーザによって影響を受けた場合があることを検証する。それを検証する１つの方法の一例は、命令create/apply/delete --server-dry-run --as <username>を有するＫｕｂｅｒｎｅｔｅｓコマンド行kubectlを使用することによる。それを検証する別の方法は、kubectl auth can-i create <object> --as <username>を使用することである。

【0062】

上記の説明は簡略化されていることに留意されたい。本開示のいくつかの実施形態によれば、コード・ファイルに対してユーザによって行われた変更は、影響を受けたオブジェクトおよび動作を検出するためにさらに分析される可能性がある（例えば、ファイルの追加はkubectl createを意味し、ファイルの削除はkubectl deleteを意味する。ファイルが複数のオブジェクト定義を含むときにファイル内のどのオブジェクトが影響を受けたかを判定するために、Git diffの出力を分析することにより、きめの細かい分析が提供される可能性がある）。さらに、上記の説明は、すべての変更がデフォルトの名前空間に適用されることを記載するが、認可チェック・エージェント４２０内のより正確な分析は、動作ごとの名前空間を決定することができる。これは、オブジェクトのメタデータから名前空間を取り出すことによって行われる場合がある。上記のテスト結果は、ユーザによって行われた変更がクラスタ上で認可されるか否かを判定する。結果は、プル要求に記録される（例えば、結果は構成管理システムに戻され、プル要求内に更新される場合がある）、プル要求を中断するために使用される、および（例えば、プル要求コメントをポストすることによって）ユーザ・インターフェース内に反映されるなどの場合がある。

【0063】

上記の例に加えて、ＧｉｔとＫｕｂｅｒｎｅｔｅｓとの間の認可チェック互換性の場合、Ｇｉｔ認可はリポジトリごとに割り当てられ、通常、読取り専用（例えば、公的Ｇｉｔアクセス）、読み書きアクセス（例えば、コラボレータ）、および管理者（例えば、様々な管理タスク）にグループ化される。しかしながら、Ｋｕｂｅｒｎｅｔｅｓは、任意のアクセス制御ロジックを実装することを可能にするために、ＲＢＡＣ（役割ベースのアクセス制御）～ＡＢＡＣ（属性ベースのアクセス制御）およびウェブフックを含む、いくつかの認可メカニズムを有する。例えば、ＲＢＡＣルールは、主導者（ユーザまたはサービス・アカウント）に関連付けられ、主導者が特定の名前空間（例えば、展開するために自分のチームに割り当てられた名前空間）内の特定のオブジェクト・タイプ（例えば、ポッド、サービス、シークレット）に対して動作（例えば、列挙、読取り、書込み、削除）することを可能にする。ＲＢＡＣに基づく名前空間に加えて、すべての名前空間内のオブジェクトに対するアクセス権限を許諾することができるクラスタ・ワイドの役割も存在する。Ｋｕｂｅｒｎｅｔｅｓオーケストレーション・システムに関係する例を通して、ＲＢＡＣメカニズムは、例示的なアクセス制御メカニズムとして使用されるが、任意のメカニズムが使用されてもよく、適用可能である。

【0064】

本開示のいくつかの実施形態によれば、認可チェック・エージェント４２０は、直接の１：１マッピングを用いて、または手動調整を介して、または好ましくは外部認証メカニズム（例えば、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、オープンＩＤコネクト（ＯＩＤＣ））を使用して、ＧｉｔとＫｕｂｅｒｎｅｔｅｓとの間の認可互換性をチェックするために、ＧｉｔユーザとＫｕｂｅｒｎｅｔｅｓユーザとの間をマッピングする。ユーザ名が異なり、Ｋｕｂｅｒｎｅｔｅｓ内の各ユーザへの異なる認可アクセスを有する異なるユーザ名が存在する場合、マッピングは、Ｇｉｔユーザ名を適切なＫｕｂｅｒｎｅｔｅｓ主導者にマッピングする、変換テーブルを含むマッピング・ファイルを用いて行われる。マッピング・ファイルは、Ｇｉｔ内で維持され、同様の審査および承認フローを受ける場合がある。マッピング・ファイルの場所は、リポジトリのために選ばれたディレクトリ編成に依存する場合がある（例えば、マッピング・ファイルは現在のディレクトリからロードされる）。

【0065】

本開示のいくつかの実施形態によれば、Ｇｉｔ内に実装された認可チェック・エージェント４２０は、異なる場所で動作し、異なる実行時間を使用することができる。これは、通知を受信し、応答して何らかのユーザ・コードを実行することを可能にする任意の適切なメカニズムを含む場合がある。それは、シェル・スクリプトまたはコンテナ画像あるいはその両方の実行を可能にする、ＪｅｎｋｉｎｓおよびＣｉｒｃｌｅＣＩなどのＣＩ／ＣＤシステムであってもよく、それはまた、機能（すなわち、クラウド・プロバイダ上で、自社運用で、またはコード・バージョン管理システムの一部として動作するファンクション・アズ・ア・サービス（ＦａａＳ））から構成されるシステムであってもよい。

【0066】

上記の例に加えて、上記に列挙されたserver-dry-runおよびauth can-iを含む、Ｋｕｂｅｒｎｅｔｅｓ認証の検証として様々な方法が使用されてもよい。加えて、手動偽装（すなわち、特定のユーザのためのアクセス認証情報をクラスタから取り出すこと）が使用されてもよい。

【0067】

任意選択で、Ｋｕｂｅｒｎｅｔｅｓクラスタに対するすべての修正は、特別管理者ユーザを使用して認可チェック・エージェント４２０によって行われ、特別管理者ユーザは、Ｇｉｔ内のファイル内のすべてのタイプの変更ならびにＫｕｂｅｒｎｅｔｅｓ内のすべてのタイプのオブジェクトおよび動作に対する認可アクセスを所有する。加えて、特定のユーザ名を使用して認可チェック・エージェント４２０に修正を実際に適用させるために、上述されたように、手動偽装が使用されてもよい。本開示のいくつかの実施形態によれば、構成変更によって影響を受けたオブジェクトの特定は、リポジトリ構成および使用されているＧｉｔＯｐｓツールに依存する可能性がある。例えば、ユーザは、リポジトリ内のディレクトリとして名前空間を表すことを選び、各ファイルが単一の構成オブジェクトを含むことを要求する可能性がある。そのような場合、名前空間（すなわち、ディレクトリ）および動作（すなわち、変更タイプ：ファイルの追加または削除）は変更セットから明らかである。あるいは、認可チェック・エージェント４２０は、（例えば、各ファイルが複数のオブジェクトを含むとき、または使用されるツールがディレクトリによって名前空間を分離しないとき）ファイルを構文解析して影響を受けたオブジェクトおよびそれらの名前空間を検出する必要があるはずである。

【0068】

本開示のいくつかの実施形態によれば、最も単純なケースでは、Ｇｉｔ内の各リポジトリは、Ｋｕｂｅｒｎｅｔｅｓ内の特定のクラスタ（または同様に構成されたクラスタのセット）を、外部構成から推論されるか、または認可チェック・エージェント４２０の構成に記憶されたターゲット・クラスタのアクセス情報と照合する。本開示のいくつかの他の実施形態によれば、ユーザは、Ｇｉｔブランチを使用して異なる動作環境（例えば、テスト、ステージング、製作）を表すことができる。

【0069】

本開示のいくつかの実施形態によれば、認可チェック・エージェント４２０は、違法なオブジェクト識別情報（例えば、タイプ、名前、名前空間）を含む、任意の検証失敗を記録する。同じ情報は、ＧｉｔＯｐｓツール・ストレージおよびユーザ・インターフェースを更新するために、または承認もしくは（ユーザが検閲者／譲受人としてマークされた場合）変更要求、およびプル要求コメントなどの形式でＧｉｔプル要求に直接フィードバックを提供するために使用されてもよい。

【0070】

本開示のいくつかの実施形態によれば、部分的に拒絶された（すなわち、変更の一部が承認され、変更の一部が拒絶された）複数のオブジェクトに対する変更を有する変更セットの認可チェックの場合、認可チェック・エージェント４２０は、認可チェック・エージェント４２０によって送信されたプル要求コメントを介してユーザ・インターフェースに報告される承認された変更および拒絶された変更を適用することを可能にする。この場合、認可チェックは、展開時間の直前または間に、すなわち、変更が承認され（例えば、Ｇｉｔ内のマスタ・ブランチに）マージされた後にのみ、実行される。認可チェックに合格したオブジェクトは、他のオブジェクトが認可チェックに失敗したときでも、無効な構成変更がバージョン管理にマージされることを遮断されないことを犠牲にして、展開に成功することができる。認可チェック・エージェント４２０は、さらなる報告／警告メカニズムを使用して、Ｓｌａｃｋ、およびＰａｇｅｒＤｕｔｙなどのそのような展開不可のオブジェクトが検出されたときに通知することができる。あるいは、認可チェック・エージェント４２０は、Ｇｉｔプル要求自体に対するコメントとして、または（展開）結果ファイルを追加することによって報告する。拒絶された変更は、次の変更セット内で訂正される場合があるので、この場合、いくつかの重要な変更がより早く適用されることが可能になる。このモードでは、クラスタ状態は、Ｇｉｔに格納された真実を語る資料とは異なる場合がある。いくつかのＧｉｔＯｐｓツールによって可能にされながら、このモードは、しばしば、偏差を強調するために差分ツールと連携して使用される。本開示のいくつかの他の実施形態では、部分的に拒絶された複数のオブジェクトに対する変更を有する変更セットの認可チェックの場合、すべての変更セットは拒絶される。

【0071】

本開示のいくつかの実施形態によれば、場合によっては、Ｇｉｔはオブジェクト・テンプレートを保持し、適用される最終的なオブジェクト構成を保持しない（例えば、それらはＫｕｓｔｏｍｉｚｅなどのツーリングを使用してテンプレートから生成される）。これらの場合、認可チェック・エージェント４２０は、アクセスを検証する前にテンプレートから実際のかつ最終的なオブジェクト構成を生成するために行われる任意の前処理ステップを起動する必要がある。

【0072】

本開示のいくつかの他の実施形態によれば、宛先クラスタは、マルチ・クラスタ管理ツール（例えば、Ｋｕｂｅｒｎｅｔｅｓ Ｆｅｄｅｒａｔｉｏｎ（ＫｕｂｅＦｅｄ）ｖ２）などのいくつかの外部ツールによって発見される。これらの場合、認可チェック・エージェント４２０は、宛先クラスタを決定するために行われる任意の前処理ステップを起動し、その後検証を処理する必要がある。すべての宛先クラスタが同じセキュリティ構成を有する場合、検証はクラスタのうちの１つに対して行われてもよい。

【0073】

本開示のいくつかの実施形態によれば、ＲＢＡＣベースの検証がＧｉｔアーチファクトにわたってサポートされるが、直接kubectlアクセスによるクラスタ修正を防止することが望ましいとき、それは、トランスポート・レイヤ・セキュリティ（ＴＬＳ）接続を介してクライアント認証を要求するか、または認可チェック・エージェント用の専用仮想プライベート・ネットワーク（ＶＰＮ）アクセスを使用し、すべての他のパブリック・アクセスをブロックして、ＡＰＩマネージャ・クライアントまたは（ＡＰＩマスタのみを含む）別個の検証クラスタの制限されたインターネット・プロトコル（ＩＰ）セットなどの外部ツールで実装することができる。

【0074】

本開示のいくつかの他の実施形態によれば、Ｇｉｔ内のプル要求検証プロセスの一部として、変更セットがアクセス制御のために確かにチェックされたことをＧｉｔＯｐｓフロー制御が検証することを可能にするために、二次検証ループが追加される場合がある。例えば、何らかのカスタム・リソース定義（ＣＲＤ）を作成することにより。ＣＲＤは、正準セットの一部ではないさらなるオブジェクト・タイプ（例えば、ポッド、サービス、展開）を管理するようにＫｕｂｅｒｎｅｔｅｓを拡張する方法である。ＣＲＤは、Ｋｕｂｅｒｎｅｔｅｓ内で作成し操作することができる新しいオブジェクト・タイプを定義する。それは、新しいタイプのオブジェクトに関係するライフサイクルおよびアクションを管理する制御コードを備えている。二次検証ループは、プル要求の暗号署名された検証結果を取り込むために何らかのＣＲＤを作成することにより、または（要求ヘッダもしくは同様のものを介して監査ログを相互に関連付けるためにプル要求識別の変更セットを使用して）テストがクラスタに対して確かに実行されたことを確認するために、ＡＰＩマスタの監査記録／アクセス・ログの使用を介して追加されてもよい。

【0075】

本開示のいくつかの実施形態によれば、構成管理システムを実装するための別の例は、構成管理システムのみのために特定のＫｕｂｅｒｎｅｔｅｓクラスタを使用することによってであり、そこにはすべてのオブジェクトが格納され、オブジェクト内のすべての変更が記録され、追跡される場合がある。この場合、リモート・クラスタは、特定のクラスタにアクセスして、それに関係する変更を適用し、その結果、リモート・クラスタのグループは、特定のクラスタにアクセスして、関係する変更を各クラスタに適用する。

【0076】

本開示のいくつかの実施形態によれば、構成管理システムとオーケストレーション・システムとの間の認可互換性をチェックするためのコンピュータ・プログラム製品が開示される。本コンピュータ・プログラム製品は、１つまたは複数のコンピュータ可読記憶媒体、および１つまたは複数のコンピュータ可読記憶媒体に一括して記憶されたプログラム命令を含み、プログラム命令は、
コンピューティング・クラスタの構成を定義する少なくとも１つのファイル内の少なくとも１つの変更を承認する要求を識別するプログラム命令と、
少なくとも１つの変更を実行するためのユーザの識別情報を構成管理システムのリポジトリから取り出すプログラム命令と、
オーケストレーション・システムに供給されたクエリに応答して受信された拒絶応答または承認応答を取得するプログラム命令であって、クエリがユーザの識別情報を使用して少なくとも１つのファイルを変更する権限に関する、プログラム命令と、
承認応答に応答して、認可互換性をチェックすることが承認されていることを確認するために、構成管理システムに承認応答を入力するプログラム命令と、
受信された拒絶に応答して、構成管理システムにメッセージを送信するプログラム命令であって、認可互換性をチェックすることが承認されていないことをメッセージが示す、プログラム命令と
を含む。

【0077】

本開示の他のシステム、方法、特徴、および利点は、以下の図面および発明を実施するための形態を説明すると、当業者には明らかであるか、または明らかになる。すべてのそのようなさらなるシステム、方法、特徴、および利点は、この説明内に含まれ、本開示の範囲内であり、添付の特許請求の範囲によって保護されることが意図される。

【0078】

本発明の様々な実施形態の説明は例示目的で提示されているが、開示された実施形態に徹底または限定するものではない。記載された実施形態の範囲および思想から逸脱することなく、多くの修正および変形が当業者には明白であろう。本明細書で使用された用語は、実施形態の原理、実際の用途、もしくは市場で見つかる技術に対する技術的な改善を最も良く説明するために、または他の当業者が本明細書に開示された実施形態を理解することを可能にするために選択された。

【0079】

本出願から満期になる特許権の存続期間中に、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための多くの関連する方法およびシステムが開発されることになり、構成管理システムとコンピューティング・クラスタのオーケストレーション・システムとの間の認可互換性をチェックするための方法およびシステムという用語の範囲は、先験的にすべてのそのような新しい技術を含むことが意図される。

【0080】

本明細書で使用されるように「約」という用語は、±１０％を指す。

【0081】

用語「備える」、「備えている」、「含む」、「含んでいる」、「有している」、およびそれらの同根語は、「含んでいるが限定されない」を意味する。この用語は、「から構成される」および「から本質的に構成される」という用語を包含する。

【0082】

「から本質的に構成される」という語句は、組成または方法が、さらなる成分またはステップあるいはその両方を含む場合があるが、さらなる成分またはステップあるいはその両方が、特許請求された組成または方法の基本的で新規の特性を実質的に改変しない場合だけである。

【0083】

本明細書で使用されるように単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈が明確に他を示さない限り、複数形の参照を含む。例えば、「一化合物」または「少なくとも１つの化合物」という用語は、それらの混合物を含む複数の化合物を含んでもよい。

【0084】

「例示的」という単語は、「代表例、具体例、または例証として働くこと」を意味するために本明細書で使用される。「例示的」として記載された任意の実施形態は、必ずしも、他の実施形態と比べて好ましいか有利であると解釈されるべきではなく、かつ／または他の実施形態からの特徴の組込みを排除するべきではない。

【0085】

「任意選択で」という用語は、「いくつかの実施形態では提供され、他の実施形態では提供されない」を意味するために本明細書で使用される。本発明の任意の特定の実施形態は、そのような特徴が競合しない限り、複数の「任意選択の」特徴を含んでもよい。

【0086】

本出願全体を通して、本発明の様々な実施形態が範囲フォーマットで提示される場合がある。範囲フォーマットの記述は単なる便宜と簡潔さのためであり、本発明の範囲に対する柔軟性のない制限として解釈されるべきではない。したがって、範囲の記述は、具体的に開示されたすべての可能な部分範囲ならびにその範囲内の個々の数値を有すると見なされるべきである。例えば、１～６などの範囲の記述は、１～３、１～４、１～５、２～４、２～６、３～６などの具体的に開示された部分範囲、ならびにその範囲内の個々の数、例えば、１、２、３、４、５、および６を有すると見なされるべきである。これは、範囲の広がりにかかわらず当てはまる。

【0087】

本明細書に数値範囲が示されたときはいつでも、それは、示された範囲内の任意の引用された数字（分数または整数）を含むという意味である。第１の指示数と第２の指示数との「間に及んでいる／及ぶ」および第１の指示数「から」第２の指示数「まで及んでいる／及ぶ」という語句は、本明細書では互換的に使用され、第１の指示数および第２の指示数ならびにそれらの間のすべての分数および整数を含むように意図されている。

【0088】

明確にするために別々の実施形態との関連で記載された本発明のいくつかの特徴は、単一の実施形態の中の組合せで提供されてもよいことを諒解されたい。反対に、簡潔にするために単一の実施形態との関連で記載された本発明の様々な特徴は、別々に、または任意の適切な部分的組合せで、または本発明の任意の他の記載された実施形態に適したものとして提供されてもよい。様々な実施形態との関連で記載されたいくつかの特徴は、実施形態がそれらの要素なしに無効でない限り、それらの実施形態の不可欠な特徴と見なされるべきではない。

【0089】

本明細書で言及されたすべての公開、特許、および特許出願は、個々の公開、特許、または特許出願が引用により本明細書に組み込まれると具体的かつ個別に示された場合と同じ程度まで、それらの全体が引用により本明細書に組み込まれる。加えて、本出願における任意の参照の引用または識別は、そのような参照が本発明に対する従来技術として利用可能であることの承認として解釈されるべきではない。項目見出しが使用される限りでは、それらは必ずしも限定的であると解釈されるべきではない。

【図1】

【図2】

【図3】

【図4】