ものすごく暑い。クーラーというものが発明されていなかったら、もう今年あたりで人類が滅びていたんじゃないかと。熱といえば、コロナワクチン接種後の発熱について、以前こんな話を聞いたことがある。
「ワクチン接種後の発熱で体温がどこまで上がるか試しているんです。50度くらいまでいくのかとか。」
水銀体温計には42度までしかない。まぁ、体温42度が1時間も続けば、死を覚悟しなければならないのだが。当の本人は、解熱鎮痛剤で下げることができると思っていたらしい。
しかし、体温が43度以上になってしまえば、多分、いくら冷そうと、解熱鎮痛剤を飲んでも無駄。体内のタンパク質が編成しているので。
つまり、この話の主は「ゆで卵は冷やせば生卵に戻る」と考えていた様子。
ぜひ、ゆで卵を冷やしてみてほしい。実際は、ゆで卵を冷やすと殻が剥けやすくなるだけで「冷やしたゆで卵」は「ゆで卵」なだけだから。
閑話休題
以前かいた記事 Azure Powershellで非対話型でログインする方法 のアクセス数は以前多く、みんな同じことを考えているんだなぁと実感。
自分自身は、azcliに移ってしまったので使っていないが、よく考えたら毎回az loginそれも、リモートシェル経由なので、デバイスログインをしている。認証を楽にする方法がないか？同じ方法でできるんじゃないかと。できた。
az loginでログインをする。コマンドライン引数は、環境に依存するので注意（それが今回の記事を書こうと思った一番の理由）
az login
az account showを実行
az account show
出力結果
{
"environmentName": "AzureCloud",
"homeTenantId": "XXXXXXXXXXXXXXXXXXXXXXXXXX,
"id": "YYYYYYYYYYYYYYYYYYYYYYYYYYY",
"isDefault": true,
"managedByTenants": [],
"name": "Azure サブスクリプション 1",
"state": "Enabled",
"tenantId": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
"user": {
"name": "hogehoge@example.com",
"type": "user"
}
}
よく見ると、ユーザ認証でログインしていることがわかる。この出力の以下をメモする。
tenantId：XXXXXXXXXXXXXXXXXXXXXXXXXX (テナントID）
id：YYYYYYYYYYYYYYYYYYYYYYYYYYY (サブスクリプションID)
ログインに使うアプリケーションの作成
#az ad sp create-for-rbac –name <アプリケーションの適当な名前> –role Contributor –scopes /subscriptions/<サブスクリプションID>
上記の例だと
az ad sp create-for-rbac --name myshell-login --role Contributor --scopes /subscriptions/YYYYYYYYYYYYYYYYYYYYYYYYYYY
実行すると以下のような表示が出てくる。
{
"appId": "PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP",
"displayName": "myshell-login",
"password": "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ,
"tenant": "XXXXXXXXXXXXXXXXXXXXXXXXXX"
}
これでできた。ちなみに有効期限を指定していないのでこの場合1年でこの認証は期限切れしてしまう。オプションをつけて期限を設定も可能。
一旦ログオフ
az logout
再度、azureへログイン。今度はアプリケーション認証でログイン。デバイス認証がいらなくなる。
#az login –service-principal –username <appId> –password <password> –tenant <tenant>
az login --service-principal --username PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP --password ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ --tenant XXXXXXXXXXXXXXXXXXXXXXXXXX
とするとログインができる。さらに、この情報はキャッシュされているので、次回からは、az loginすら不要。いきなりコマンドが実行できる。
この環境で、az account showを実行すると
{
"environmentName": "AzureCloud",
"homeTenantId": "XXXXXXXXXXXXXXXXXXXXXXXXXX,
"id": "YYYYYYYYYYYYYYYYYYYYYYYYYYY",
"isDefault": true,
"managedByTenants": [],
"name": "Azure サブスクリプション 1",
"state": "Enabled",
"tenantId": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
"user": {
"name": "PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP",
"type": "servicePrincipal"
}
}
名前がアプリケーションIDでユーザではなく、servicePrincipalでログインしていることがわかる。EntraIDのEnterprise Applicationにも作成したアプリケーションが表示されているはず。
ちなみに、この設定をすると、PowershellでもConnect-AzAccountが不要になる。逆に、PowerShellでアプリを作ってログイン設定をした場合も同じ。これは便利。これで手元の手順書からログイン処理を記述する必要がなくなる。
注意
この方法は便利だが、この設定をした人が組織から離れた、退職してしまった場合でも、この環境にアクセスができてしまう。よって、Enterprise Applicationの管理はかなり重要。Enterprise Applicationを自動で作ってくれるソフトウェアもあるが、そんなの許している場合ではない（使わないほうがいい。）また、組織でこういう設定を許している場合でも設定しないほうがいい。あらぬ疑いがかけられるかもしれないし。
自分の検証は、完全に自分の環境でやっているので問題はないが。。。
「どこに書いてあったんですか？誰が言ったんですか？サポーティブですか？」という質問がまたくるかもしれないので、答えておくが。
これは「ChatGPT」に聞いただけ。
もう、この手のやり方系のブログはだんだん必要がなくなってきてしまうのではないかと思う。AIに聞けば何も知らない状態でもイチから教えてくれるので。。。
「どこに書いてあったんですか（略）」の人の動きをみていると、
- 聞く内容の発見（聞こうと思う自分からの動機）がなく、事象に対して、すぐに「どこに書いてあったんですか？（略）」の行為に移行してしまう。検索エンジンの結果が全て。
- AIにプロンプトを入れる時に、これくらいは言わなくてもわかるでしょうという感じでパラメーターが異様に少ない。（プロンプトが弱いので、AIが持っている引き出しが引き出せない。あるいは相当時間がかかる。）
この２つをあらためて考えてみると、まるで親が健在で何でもやってくれる状況に置かれている人の振る舞いに似ている。
AIは、出来の悪い子供にうまく結果をだしてもらうように、これでもか！というくらいの情報を渡さないとAIが持っている引き出しが出てこないような気がする。