Azure Automationの仕組みと設定内容

#### はじめに
Azureでリソース管理をするにあたって、Powershellが使えるAutomationが便利だと思って利用を試みてみたものの、他の一般リソースと少々毛色が異なり混乱した為、Automationの動く仕組みについて備忘がてら記載します。
引用、参考文献は↓こちらになります。
[TechNet:Azure Automation でリソース管理を自動化するには](https://blogs.technet.microsoft.com/jpaztech/2016/04/25/how-to-use-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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/515252/94cb9480-96be-c68d-2edb-0ee7e5322a43.png)

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

![07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/515252/d70d5f13-5ee2-d259-91c7-6bf4c3f3b88e.png)

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

``` powershell: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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/515252/2094d96b-3ad0-da07-8596-4ffdec9451e3.png)

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

![12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/515252/7f84a366-a770-a716-9214-96fdd73650b1.png)

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

![09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/515252/9c7fecf1-7d69-5b50-a6b6-5c18a1b2a331.png)

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

![10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/515252/b47486ca-28ed-4fda-255c-a895750c04be.png)

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

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

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