10
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Azure Automationの仕組みと設定内容

Posted at

はじめに

Azureでリソース管理をするにあたって、Powershellが使えるAutomationが便利だと思って利用を試みてみたものの、他の一般リソースと少々毛色が異なり混乱した為、Automationの動く仕組みについて備忘がてら記載します。
引用、参考文献は↓こちらになります。
TechNet:Azure Automation でリソース管理を自動化するには
[MS:Azure Automation の実行アカウントを管理する]
(https://docs.microsoft.com/ja-jp/azure/automation/manage-runas-account)
[MS:リソースにアクセスできる Azure AD アプリケーションとサービス プリンシパルをポータルで作成する]
(https://docs.microsoft.com/ja-jp/azure/active-directory/develop/howto-create-service-principal-portal)

Azure Automationについて

1. Automationリソース

Azure AutomationリソースをPortalから作成すると、Automationアカウントというものとチュートリアル用の実行ファイルのようなものが自動で作成されます。

06.png

何も考えなくても作成時に「実行アカウントを作る」を選択すれば、後はスクリプトを書いて実行するだけで特に問題なく実行できます。
ただ、Automationアカウントとは何かいまいち分からず、マニュアルやサンプルスクリプトを見ても単純にPortalのコンソール機能を利用したコマンド実行とは少し違う作法が必要そうであることが分かります。

07.png

チュートリアルスクリプトを見るとわかるのですが、Automationへ「AzureRunAsConnection」という固定の名前を使って認証情報をオブジェクトに挿入しています。

AzureAutomationTutorialScript.ps1
$connectionName = "AzureRunAsConnection"
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName         

このAzureRunAsConnectionというのがAutomation機能のキモになっているようです。

2. AzureRunAsConnection

「AzureRunAsConnection」とはなんなのかを探すと、Automationアカウントの「共有リソース」内に「接続」という設定があり、ここに同じ名前の接続設定があります。 これにAutomationがAzureリソースを管理する為の認証情報が含まれています。接続情報に含まれている内容は以下があります。

  • 接続タイプ(ASMかARMか両方互換)
  • テナントID(Azure ADのID)
  • サムプリント(証明書のID)
  • サブスクリプションID 

11.png

接続タイプについてはAzure/AzureClassicCertificate/AzureServicePrincipalと種類がありますが、それぞれ両方互換/ASM/ARMへの対応となっており、ASMに対応する場合は必要な証明書の種類が異なります。ARMの場合はサービスプリンシパルを作成する必要があります。(詳細は↑の参考文献を参照のこと)
AutomationアカウントはADにアプリとして登録される事でドメインユーザのような形をとり、他リソースへのアクセスに証明書を使った暗号化通信を行っています。
これはオンプレシステムでジョブ運用をする際の実行ユーザ設定とほぼ同じ役割になります。
この実行ユーザとしての設定をまとめたものが「アカウント設定」項目にある「実行アカウント」です。

12.png

3. Automationの実行権限

オンプレでのジョブ実行における実行ユーザの役目と記載しましたが、ではこの実行ユーザが持つ権限はどこで設定されているのかというと、既定ではサブスクリプションのアクセス許可からAutomationに割り当てられたロールを確認する事ができ、自動で作成した場合は「サブスクリプションの共同作成者」のロールが割り当てられます。

09.png

ARMでリソースを作成している場合はこの権限を必要な権限にチューニングすることが可能です。(JP1で言うOSユーザマッピングみたいなイメージ)
案件によっては既定のロールだと権限が強すぎる為、リソースグループ単位でスコープを小さく設定する必要があるかもしれません。
ちなみにASMでは権限の変更はできません。
※管理証明書を使って認証するからではないかと思いますが。。。

10.png

4. 実行ユーザの作成

Automationアカウントに上記の実行権限を付与するにはいくつか方法があり、一番簡単なのがリソースを作成する際に作成する方法です、もしくはリソース作成後「実行アカウント」設定から自動作成が可能です。 この方法を利用すると既定の接続名(AzureRunAsConnection)と自己証明書と既定のアプリケーション名(automation_~)で、既定のロールが割り当てられた状態で実行ユーザが作成されます。
これらをカスタマイズしたい場合(違う証明書を使いたいなど)は、MSで提供されているスクリプトを実行する事で実行ユーザの作成が可能です。
[MS:Azure Automation の実行アカウントを管理する]
(https://docs.microsoft.com/ja-jp/azure/automation/manage-runas-account)

おわりに

リソース管理をするにあたって、実行ユーザのロール管理と証明書については最低限設計をしなければいけないことが分かりました。
また証明書については更新を実施する必要が出てきた為、運用設計がががが。
でも、Automationは外に出ないサービスの為、無理にEnterprise版証明書を利用する必要はないと思います。(証明書はあくまでサブスクリプション内のリソース間の暗号化に使うもののため)

うーん、これはこれで面倒くさい。。。

10
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?