SAP云平台

Netweaver

同SAP云平台一样，在事务码PFCG里维护角色:

然后在事务码SU01里将多个角色分配给用户：

Kubernetes

Kubernetes在1.3版本中发布了alpha版的基于角色的访问控制（Role-based Access Control，

RBAC）的授权模式。相对于基于属性的访问控制（Attribute-based Access Control，

ABAC），RBAC引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。这个概念和SAP Cloud for Customer的RBAM(Role based Authorization Management)是一致的。

在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略可以

跟某个角色关联，具体的用户再跟一个或多个角色相关联。

C4C

所有的business role：

在工作中心Administration->General Setting里将Business Role分配给用户：

顾名思义，ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。

ConfigMap同Kubernetes的另一个概念secret类似，区别是ConfigMap主要用于保存不包含敏感信息的明文字符串。

创建方式：

kubectl create configmap special-config --from-literal=i042416=jerry

上述命令行创建了一个名为special-config的键值对，

key为i042416, 值为jerry

接下来我希望用这个key为i042416的值"jerry"来定义成pod里的一个环境变量。

下面是我的yaml文件：

apiVersion: v1

2 kind: Pod

3 metadata:

4 name: jerry-config-pod

5 spec:

6 containers:

7 - name: test-container

8 image: gcr.io/google_containers/busybox

9 command: [ “/bin/sh”, “-c”, “env” ]

10 env:

11 - name: JERRY_NAME

12 valueFrom:

13 configMapKeyRef:

14 name: special-config

15 key: i042416

16 restartPolicy: Never

可以看到第15行引用了我的ConfigMap的key：i042416

下面使用create -f将该yaml文件导入，创建一个新的pod：

创建之后，能在pod的明细页面看到configMap的key已经作为环境变量显示出来了：

因为我yaml文件里指定pod执行的script为/bin/sh -c env, 因此最后会将容器里所有的环境变量都打印出来，我们定义在ConfigMap里的i042416的值jerry也被显示了出来：

这种定义环境变量的做法和SAP云平台CloudFoundry环境里定义环境变量的方式很类似。

CloudFoundry环境变量一览表：

https://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html

• CF_INSTANCE_ADDR
• CF_INSTANCE_GUID
• CF_INSTANCE_INDEX
• CF_INSTANCE_IP
• CF_INSTANCE_INTERNAL_IP
• CF_INSTANCE_PORT
• CF_INSTANCE_PORTS
• DATABASE_URL
• HOME
• LANG
• MEMORY_LIMIT
• PORT
• PWD
• TMPDIR
• USER
• VCAP_APP_PORT
• VCAP_APPLICATION
• VCAP_SERVICES

当使用cf push命令将本地应用部署到SAP云平台的CloudFoundry环境下时，某些环境变量会自动被系统写入相应的值，这个行为同ABAP的sy-sysid自动被设置为当前系统ID具有一样的逻辑。

比如app router会把用户访问请求重定向到XSUAA实例上。

app router在manifest.yml里定义的XSUAA实例名称为xsuaa-jerry-demo，

在运行时这个XSUAA的id会被SAP云平台自动写入环境变量VCAP_SERVICES里：

要获取更多Jerry的原创文章，请关注公众号"汪子熙".