AIが興隆を迎える近年、さまざまな企業が独自の大規模言語モデルをリリースしています。こうした大規模言語モデルをチェスの標準的なAIと対戦させた結果、多くの大規模言語モデルが惨敗する中、「gpt-3.5-turbo-instruct」だけが好成績を残したことが報告されています。
大規模言語モデルとチェスAIで対決させるとほとんどの大規模言語モデルがズタボロに負ける中なぜか「gpt-3.5-turbo-instruct」だけが圧倒的勝利 - GIGAZINE
⇧ 例外が確認されたものの、概ね「特化型」には敵わないってことなんかね？
AIも人間と同様、適切な訓練が重要ってことなんですかな。
「特化型」を寄せ集めて、「大規模言語モデル」を作れないものなんですかね？
結果はどうなるか分からないですが、「PoC（Proof of Concept）」的なものを手掛けて欲しい気はするのですが、開発コストがかかり過ぎるのか、それとも技術的に不可能なのか、そういった試みの話を聞きませんな。
HashiCorp Vaultとは
公式のドキュメントによりますと、
What is Vault?
HashiCorp Vault is an identity-based secrets and encryption management system. It provides encryption services that are gated by authentication and authorization methods to ensure secure, auditable and restricted access to secrets.
⇧ 情報を暗号化して、アクセス制限なども管理してくれるサービスらしい。
ちなみに、「HashiCorp」はというと、
HashiCorpは、カリフォルニア州サンフランシスコを拠点とするフリーミアムビジネスモデルを持つソフトウェア会社である。
HashiCorpは、開発者、オペレーター、セキュリティ専門家がクラウドコンピューティングインフラストラクチャのプロビジョニング、保護、実行、接続を可能にするソースアベイラブルのツールとプロプライエタリの製品の両方を提供している。
⇧ とあり、Wikipediaの情報を整理すると、
| No | サービス | リリース |
|---|---|---|
| 1 | Vagrant | 2010年 |
| 2 | Packer | 2013年6月 |
| 3 | Terraform | 2014年7月 |
| 4 | Consul | 2014年4月 |
| 5 | Vault | 2015年4月 |
| 6 | Nomad | 2015年9月 |
| 7 | Serf | 2013年 |
| 8 | Sentinel | 2017年 |
| 9 | Boundary | 2020年10月 |
| 10 | Waypoint | 2020年10月 |
とあり、「Vagrant」や「Packer」、「Terraform」なども有名ですな。
話を「HashiCorp Vault」に戻すと、
⇧ 4つの段階があるようです。
今回は、「Access」の話についてになるということなのかな。
話を脱線すると、
By default, Vault uses Shamir's Secret Sharing to split the unseal key into a configured number of shards (key shares or unseal keys). A precise number of shards are required to reconstruct the unseal key, which is then used to decrypt the Vault's root key.
https://developer.hashicorp.com/vault/docs/internals/architecture
⇧ 管理者とかの場合は、「Unseal」という概念を意識する必要があるそうな。
HashiCorp VaultのREST APIの利用にも認証が必要のようなのだけど...
で、管理者などが「HashiCorp Vault」のユーザーを作成してくれて、連携された認証情報で「HashiCorp Vault」にログインすると、ユーザーには「Service tokens」というものが発行されるっぽい。
「HashiCorp Vault」の「Token」は、
Tokens
Tokens are the core method for authentication within Vault. Tokens can be used directly or auth methods can be used to dynamically generate tokens based on external identities.
⇧ とあり、「HashiCorp Vault」における「認証」の主要な方法であると。
でもって、
⇧ 3種類に大別できるらしいのだけど、その内の1つである「Service tokens」がユーザー用に発行されるらしい。
で、「API」のページの説明を確認すると、
Authentication
Once Vault is unsealed, almost every other operation requires a client token. A user may have a client token sent to them. The client token must be sent as either the X-Vault-Token HTTP Header or as Authorization HTTP Header using the Bearer <token> scheme.
Otherwise, a client token can be retrieved using an authentication engine.
⇧とあり、『requires a client token』とあるのだが、この「トークン」が何なのかについて全く説明が無いのでサッパリ分からない...
『Otherwise, a client token can be retrieved using an authentication engine.』
とあるのでリンクをクリックすると遷移先のページは、「Auth Methods」となっている。
ドキュメントの左サイドバーを確認した感じでは、
Auth methods
Auth methods are the components in Vault that perform authentication and are responsible for assigning identity and a set of policies to a user. In all cases, Vault will enforce authentication as part of the request processing. In most cases, Vault will delegate the authentication administration and decision to the relevant configured external auth method (e.g., Amazon Web Services, GitHub, Google Cloud Platform, Kubernetes, Microsoft Azure, Okta ...).
⇧ 認証方法が多過ぎて悶絶不可避なのだが、「Tokens」のページを確認してみると、
⇧ 詳細については、
『The Token auth method has a full HTTP API. Please see the Token auth method API for more details.』
のリンクを参照とあるので遷移先のページを確認すると、
Token auth method (API)
This is the API documentation for the Vault token auth method. For general information about the usage and operation of the token method, please see the Vault Token method documentation.
⇧ またもや、冒頭で参照先を提示されてることに発狂しそうになるのだが、
⇧ とあるように、REST APIのリクエストのヘッダーに、「トークン」を設定するようにということらしい。
ただ、肝心の『X-Vault-Token』に設定可能な「トークン」が何なのかの説明が無いため、どんな「トークン」を利用すれば良いのか皆目見当が付かないんだが...
「GitHub Apps」とかでも、
インストール アクセス トークンを使って、HTTP ベースの Git アクセスの認証を行うこともできます。 アプリには、"コンテンツ" リポジトリのアクセス許可が必要です。 その後は、インストール アクセス トークンを HTTP パスワードとして使用できます。 TOKEN をインストール アクセス トークンに置き換えます: git clone https://x-access-token:TOKEN@github.com/owner/repo.git。
⇧「x-access-token」とか何の説明も無く唐突に出てきてましたけど、何の説明もしないのがIT業界の流儀なのかね？
そして、悲報は続く...
Clients and entities
Anything that connects and authenticates to Vault to accomplish a task is a client. For example, a user logging into a cluster to manage policies or a machine-based system (application or cloud service) requesting a database token are both considered clients.
https://developer.hashicorp.com/vault/docs/concepts/client-count
⇧「entity」が何なのかの説明がないのにいきなり登場する「entity」。
最早、途方に暮れるしか無いのだが...
人間を辞めてエスパーになれということなんだろうか...
ちなみに、
⇧ 各プログラミング言語向けのHTTP Clientのライブラリが用意されてはいるのだが、そもそものHashiCorp VaultのREST APIを利用するのに必要な情報が分かり辛いのよね...
元が分かり辛いので、ライブラリでラッパーしたところで、余計にカオスなことになってるのよね...
公式のドキュメントによると、developer.hashicorp.com
Recommended architecture
The following diagram shows the recommended architecture for deploying a single Vault cluster with maximum resiliency:
https://developer.hashicorp.com/vault/tutorials/day-one-raft/raft-reference-architecture
⇧推奨する構成としては、HTTP Clientからのリクエストをロードバランサーで受けるようにして、「availability zones」を複数の構成にする、所謂「事業継続計画（BCP：Business Continuity Planning）」を想定した形にするのが望ましいということですかね？
コストが気になるところではありますが...
で、肝心のHashiCorp Vaultで管理されている「Secret」なるものを、REST APIで取得する方法なのだが、Pythonの「HAVC」のドキュメントを見る限り、
⇧ にある「KV - Version 2」の「Read Secret Versions」が該当しそうではある。
⇧ いきなり、実装例なのですが、必要な情報が全く分からないので、「hvac.api.secrets_engines.KvV2.read_secret_version()」のリンクをクリックし、遷移先のページを確認すると、
⇧「引数」とか「戻り値」の説明があるのだけど、説明の内容が全く分からない...
「戻り値」にしても、「dict」型で「The JSON response」であるとしか説明がなく、どんな形式のレスポンスなのか全く不明瞭でありますと。
「JSON」って入れ子になってるのか、フラットな形なのかハッキリしてくれないと困るんだが...
「引数」にしても、設定する値はどこで確認すれば良いのかサッパリ分からんのよね...
何と言うか、ドキュメントの書きっぷりは、もう少しどうにかならんものなのか...
で、推測するしか無いのだが、
⇧ 上図の「Secret Engine」に対してREST APIを実行すると「Secret」が取得できると。
その前に、「Auth Method」に対してREST APIを実行して、REST APIを利用するための「認証」を済ませる必要があると。
流れは、推測できたのだが、結局、必要な情報がどこで確認すれば良いのかがサッパリ分からんのよね...
ややこしいのが、
⇧「CUI」と「GUI」でアクセスURLが異なったりしてるからして、
⇧ REST APIで必要な情報との突き合わせが困難なんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
