Azure实践之如何通过邮件实现AzureVM的开关机教程

通过邮件实现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即可拥有对应的权限！无需任何用户名和密码，这种方式也是比较推荐的

下边回到我们的原始需求，来看下邮件开关机应该如何解决安全问题