通过邮件实现Azure中VM的开关机？这有可能实现吗？当然是可以的，而且其实还非常简单，今天就来分享一波吧
实际上分析这个需求可以发现，如果想通过发送一封邮件就对Azure中的环境进行操作，那么首先第一个要解决的问题就是身份验证了，邮件本身肯定是不会带credential的，一种方法是可以把用户名密码写在邮件内容里，这个当然很傻了，绝对不会推荐这么做的，另外一种方法是可以通过Azure key vault，把用户名密码写在key vault中，这种方法其实是可以的，相对来说也比较安全。之前也有分享过一些基本的用法，有兴趣的可以看看https://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的资源，不需要使用用户名密码或者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即可拥有对应的权限！无需任何用户名和密码，这种方式也是比较推荐的
下边回到我们的原始需求，来看下邮件开关机应该如何解决安全问题