通過郵件實現Azure中VM的開關機？這有可能實現嗎？當然是可以的，而且其實還非常簡單，今天就來分享一波吧
實際上分析這個需求可以發現，如果想通過發送一封郵件就對Azure中的環境進行操作，那麼首先第一個要解決的問題就是身份驗證了，郵件本身肯定是不會帶credential的，一種方法是可以把用戶名密碼寫在郵件內容裏，這個當然很傻了，絕對不會推薦這麼做的，另外一種方法是可以通過Azure key vault，把用戶名密碼寫在key vault中，這種方法其實是可以的，相對來說也比較安全。之前也有分享過一些基本的用法，有興趣的可以看看http://blog.51cto.com/mxyit/2346350
這樣總體上來說可以保證用戶密碼的可用性和安全性，但是其實這種方法也是很麻煩的，目前來說在Azure中可以做身份驗證的方法有這麼幾種
1：Azure AD 用戶credential登陸
這種方法是最傳統，也是最古老的，直接在應用程序中使用用戶名和密碼登陸，需要注意的是如何保護credential的安全性，是應該應該關注的一個重點，這種方法基本上企業是很少會用的，因爲安全性實在太差，個人用戶偶爾在測試環境用一下倒是還可以
以下是如何通過PowerShell的方式使用Azure AD 用戶密碼登陸
2：Azure service principal方式
如果有需要訪問或修改資源的代碼，則可以爲應用創建標識。 此標識稱爲服務主體。 可以將所需權限分配給服務主體，這種方式通過RBAC給service principal賦予角色，之後應用程序即可擁有對應的權限，我們在操作時可以通過Portal或者PowerShell的方式註冊一個application，我們可以通過PowerShell直接登錄，可以看到登陸方法和用戶名密碼的方式類似
3：託管標識方式
藉助 Azure Active Directory 的託管標識，應用可以輕鬆訪問其他受 AAD 保護的資源（如 Azure Key Vault）。 標識由 Azure 平臺託管，無需設置或轉交任何機密
你的應用程序可以被授予兩種類型的標識：
系統分配的標識與你的應用程序相綁定，如果刪除應用，標識也會被刪除。 一個應用只能具有一個系統分配的標識。
用戶分配的標識是可以分配給應用的獨立 Azure 資源。 一個應用可以具有多個用戶分配的標識。
這種方式不需要用戶名密碼，如果應用程序需要調用Azure的資源，不需要使用用戶名密碼或者service principal，可以使用標識向支持 Azure AD 身份驗證的任何服務（包括 Key Vault）證明身份，無需在代碼中放入任何憑據。
簡單理解來說，RBAC以前是將用戶角色分配給Azure AD的用戶，組或者是service principal，但是通過identity，我們可以直接將權限assign給app service，key vault或者是VM
以下是一些應用的案例，比如可以在app service裏找到identity，然後開啓identity
在IAM中可以看到，assign access to中不光是Azure AD user，還可以選擇其他的Azure service
當然，這個服務目前來說還只在Azure Global有，mooncake目前還沒有這個服務
這樣，web app即可擁有對應的權限！無需任何用戶名和密碼，這種方式也是比較推薦的
下邊回到我們的原始需求，來看下郵件開關機應該如何解決安全問題