Permissions

您能想到的与 OpenShift 环境的几乎每次交互都需要通过 OpenShift 的控制平面 API。所有 API 交互都经过身份验证（AuthN - 你是谁？）和授权（AuthZ - 你可以做你要求的事情吗？）。

什么是身份验证（authn）？ 身份验证意味着确保一个人或设备是他们声称的人（或什么人）。 领取活动门票的人可能会被要求出示身份证以验证身份； 类似地，应用程序或数据库可能希望通过检查用户的身份来确保用户的合法性。 身份验证确保数据不会暴露给错误的人。

什么是授权（authz）？ 授权决定了经过身份验证的用户可以看到和执行的操作。 想想当银行客户在线登录他们的帐户时会发生什么。 因为他们的身份已经过验证，他们可以看到自己的账户余额和交易历史——但他们无权查看其他人的。 相反，银行的经理可以被授权查看任何客户的财务数据。 同样，一个人可能是一家企业的合法员工，他们可能已经验证了自己的身份，但这并不意味着他们应该有权访问该企业的所有文件和数据。 例如，来自人力资源或会计部门以外的员工不应该能够看到每个人的薪酬。 用户的授权级别决定了他们有权做什么； 因此，授权操作的通用术语是“权限permissions”。 这个概念的另一个术语是“特权privileges”。

在上一个查看日志实验中，我们看到引用Service Account 时出现错误。

由于 OpenShift 是一个声明式平台，因此某些操作将由平台执行，而不是由最终用户（当他或她发出命令时）执行。这些操作是使用服务帐户执行的，服务帐户是user平台将在内部使用的一种特殊类型。这些操作是使用服务帐户执行的， Service Account是平台在内部使用的一种特殊类型的“用户”。

OpenShift 会在每个项目中自动创建一些特殊的服务帐户。默认的服务帐户 default service account 是负责运行 Pod 的帐户，OpenShift 使用此服务帐户并将其注入 启动的每个容器。通过更改这个服务帐户（SA)的权限，我们可以做一些有趣的事情。

OpenShift automatically creates a few special service accounts in every project. The default service account is the one taking the responsibility of running the pods, and OpenShift uses and injects this service account into every pod that is launched. By changing the permissions for that service account, we can do interesting things.

您可以在 Web 控制台中查看当前权限，转到 Developer Perspective 中的 Topology 视图，单击parksmap条目，转到Details选项卡，然后单击Namespace。

Namespace

然后，选择角色绑定*Role Bindings* 选项卡并按命名空间角色绑定*Namespace Role Binding*进行过滤，以便查看所选项目的所有权限。

Membership

练习：授予服务帐户查看权限

parksmap 应用程序希望与 OpenShift API 进行通信，以了解其他在 项目*中的*Pod、Services*和资源。您很快就会知道为什么！你很快就会知道为什么！The parksmap application wants to talk to the OpenShift API to learn about other *Pods, Services, and resources within the Project. You’ll soon learn why!

parkmap 应用程序在集群上的项目中作为服务帐户运行：即 default Service Account 。正是对这个服务帐户，我们可以授予必要的“视图”访问权限，这将允许它查询 API 以查看项目中的资源。这还具有解决我们之前在日志中看到的错误消息的原因的额外好处。

通过选择下列选项卡的来更新 %PROJECT% 项目中的`default` Service Account

Choose an approach represented by the following tabs to update the default Service Account in the %PROJECT% project

  • OpenShift Console

  • oc Command Line

  1. 从Workloads → Deployments页面，单击Namespace，然后单击Role Bindings，然后单击Create Binding按钮。 （管理员视图项目→project→ %PROJECT% → 角色绑定 4.9版本）

    Service account list

  2. 选择视图为角色绑定名称`％PROJECT％的命名空间，视图的角色名称，服务帐户为主题，％PROJECT％`为主题命名空间，默认为主题名称。

    Service account edit

  3. 完成编辑权限后，单击“创建”按钮。然后您应该能够Role Bindings在`%PROJECT%项目列表中看到它

    Service account changed 
oc project %PROJECT%

然后使用 oc policy add-role-to-user 命令将预定义的view 角色赋予用户：

oc policy add-role-to-user view -z default
What does the -z flag do?

From the -h output on oc policy:

-z, --serviceaccount=[]: service account in the current namespace to use as a user

The -z syntax is a special one that saves us from having to type out the entire string, which, in this case, is system:serviceaccount:%PROJECT%:default. It’s a nifty shortcut.

The -z flag will only work for service accounts in the current project. If you’re referring to a service account in a different project, use the `-n <project>`switch.

Exercise: Redeploy Application

oc rollout restart deployment/parksmap

新的deployment部署立即开始，回到拓扑视图，然后再次单击 parksmap 条目以观看其发生。你可能不够快！但它将反映在 ReplicaSet 编号中。

A new deployment is immediately started. Return to Topology view and click the parksmap entry again to watch it happen. You might not be fast enough! But it will be reflected in the ReplicaSet number.

Application deployed

如果现在查看应用程序的日志，则应该不会看到任何错误。