前言
初次入坑函数计算的小伙伴，遇见的第一大拦路虎非RAM授权相关莫属。开始玩玩hello world这种无关授权访问其他阿里云资源的时候，感觉 serverless 大法各种好，之后发现线上排查问题日志的时候，第一次给service配置role的时候，虽然控制台能成功配置，但是估计也是一脸懵逼。本文旨在用最浅显的例子说明ram的基本概念，以及和函数计算之间的关系。
RAM
RAM 中的 2 个基本概念：
用户
- 主账户（或称root用户）
- 子用户
角色
先用一个通俗的例子来说明这两个基本概念：
- 您在阿里云开通了账号，购买阿里云上的资源； 这个就类似于您创建了一个国家，国家有大有小（等价于你的阿里云上资源多少）， 主账号就是国王您， 为了让您的国家机器健康有效运转，您开始放权，从任命三省六部大员直到九品芝麻官，这个时候，官员就对应子账号， 官员（子用户）的权利有大有小，就对应国王（主账号）授予的官职大小。 此时无论国王（主账户）还是官员（子账户），都是物理意义上的人（真正的实体）， 表现为有具体的身份证（Acesskey Id 和 Acesskey Secret），身份证与人绑定。
- 角色不是实体，接着上面的例子，国家和国家之间需要交流合作， 假设您的国家是 A 国，如果 B 国想和 A 国合作， B 国派遣外交使节
甲(B国的一个官员，对应B国子用户)访问 A 国， 这个时候，A 国需要给甲颁发一个签证，不然过不了海关，甲就可以凭借这个签证，获得一个临时的 A 国国民身份进入A国，进行一些工作事项。 在这里 签证 可以理解为一个角色， 不是真正物理意义上的实体。 真正的实体甲通过签证中授予的权限，临时扮演 A 国国民身份在 A 国干一些事情。签证的权限有大有小并且有一定的时效性，甲拿着不同的签证，有可能是元首级别的交流待遇，也有可能只是去穷游7天之内必须滚来回的DS。
函数计算中的RAM
函数中直接使用用户
def handler(event, context):
# 直接明文使用AK 访问其他阿里云资源，比如oss
...
return "OK"
这种用法简单粗暴，使用ak， 在上面说了，有ak的都是真正的实体用户， 直接明文AK在代码中裸奔，怎么看都不安全，于是演变成如下的代码片段：
def handler(event, context):
ak_id = os.environ["AK_ID"]
ak_secret = os.environ["AK_SECRET"]
# 使用环境变量中ak访问其他阿里云资源
# 环境变量有加密处理，
# https://help.aliyun.com/document_detail/69777.html
...
return "OK"
这样似乎看起来很安全了，但是如果一旦出现为了安全，定期更换AK情况，就不得不到处去手动函数中设置的环境变量...
函数中使用role
回到上面角色中的那个例子，您的阿里云资源是 A 国， 函数计算的服务是 B 国， B 国和 A 国进行合作，A 国颁给 B 国大使 甲 签证（对应函数计算service配置的role）， 这个时候 甲 临时扮演成 A 国国民对 A 国的资源进行一些访问， 此时可以用如下注释理解：
# -*- coding: utf-8 -*-
def handler(event, context):
# context中的 creds 就是 `甲` 临时扮演成的 A 国国民
creds = context.credentials
# creds 可以操作 A 国（也就是您自己的阿里云）的资源
# 这样的话，您通过使用creds 就可以访问您自己的阿里云资源了
# 不需要 ak 在代码中裸奔了
...
return 'OK'
所以：
- 如果您需要将您函数的日志打印到您的 logstore 中进行调试，需要至少授予 service 访问您 logstore 的权限，不然函数计算没法把您函数执行的日志 put 到您的lostore
- 如果您没有给 service 配置 role， context.credentials为空
- 如果您想直接使用context.credentials访问您自己的阿里云资源，只需要给service中配置的role增加相应的权限就行
- 强烈推荐尽量在函数计算中使用 context.credentials 来替换明文ak 的使用方法
总结
本文以一个简单浅显的例子说明函数计算和role之间的关系，以及解释了函数计算中 service 中设置的 role 的意义，希望本文能给您拨开云雾，如果还有不太理解的地方，欢迎大家留言反馈。
