Openshift服务部署中的权限控制

一、前言

Openshift具有很优秀的权限管理机制，提供非常细粒度的权限管理。访问Openshift平台服务的方式包括GUI、命令行、API、POD运行的权限，而可能的访问实体包括自然用户、外部应用程序、内部模块、POD内程序。这些不同的访问方式和访问实体需要使用灵活的机制去进行权限赋予和权限认证。

自然用户访问Openshift平台的时候凭借用户名和密码或者kubeconfig的key文件可以在进行认证的同时被赋予一些基本的权限。外部应用程序、内部模块或者POD内程序访问的时候，没有登陆认证的过程，所以需要特殊的权限代理机制(service account)来满足对平台访问的特定需求。另外，在POD部署的时候所要求的执行环境权限(比如是否能运行root用户，能否挂载volume，能否访问主机网络环境等)需要根据执行部署的账户(user id或者 service account)的特定权限进行判断能否成功部署；而对于Openshift cluster的访问能力则需要cluster role去指定。

在Openshift环境中，具体的能力、代表能力组合的权限集合和使用权限的实体标示之间是分离定义的，权利和用户之间通过权限集合进行绑定，提供了细粒度和灵活的权力赋予和管理机制。

在Openshift中，能力包括赋予POD的能力(Linux capability)和访问Openshift平台不同服务的能力(cluster capability)两部分；代表能力组合的权限集合叫做SCC(Security Context Constrains，针对POD)和cluster role(针对)；用户分为user id或者 service account。

转载自https://blog.csdn.net/cloudvtech

二、Security Context Constrains

SCC在Openshift官方文档的描述如下：

OpenShift provides security context constraints (SCC) that control the actions that a pod can perform and what it has the ability to access.

所以SCC为一组POD内Linux系统的权限的集合，包括系统默认的SCC如下：

$ oc describe scc restricted
Name:					restricted
Priority:				<none>
Access:
  Users:				<none>
  Groups:				system:authenticated
Settings:
  Allow Privileged:			false
  Default Add Capabilities:		<none>
  Required Drop Capabilities:		KILL,MKNOD,SYS_CHROOT,SETUID,SETGID
  Allowed Capabilities:			<none>
  Allowed Seccomp Profiles:		<none>
  Allowed Volume Types:			configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
  Allow Host Network:			false
  Allow Host Ports:			false
  Allow Host PID:			false
  Allow Host IPC:			false
  Read Only Root Filesystem:		false
  Run As User Strategy: MustRunAsRange
    UID:				<none>
    UID Range Min:			<none>
    UID Range Max:			<none>
  SELinux Context Strategy: MustRunAs
    User:				<none>
    Role:				<none>
    Type:				<none>
    Level:				<none>
  FSGroup Strategy: MustRunAs
    Ranges:				<none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:				<none>

针对有不同权限需求的应用，通过建立具有不同Linux权限组合的新的SCC，可以保证应用程序POD拥有恰好的系统权限。

转载自https://blog.csdn.net/cloudvtech

三、cluster role

role在Openshift官方文档的描述如下：

Role-based Access Control (RBAC) objects determine whether a user is allowed to perform a given action within a project.

所以用户在一个Openshift能进行什么操作也可以以细粒度进行控制，比如能否删除或者建立project里面的POD，能否删除一个project等等。这个由一系列操作规则组成的role可以赋给一个user id或者一个service account。

转载自https://blog.csdn.net/cloudvtech

四、service account

service account在Openshift官方文档的描述如下：

Service accounts provide a flexible way to control API access without sharing a regular user’s credentials.

service account是用来控制非自然用户在访问Openshift平台进行服务部署的时候所具有的能力范围的，它是承载SCC和cluster role的实体。特别的，如果要在POD内部访问Openshift平台，则需要用绑定特定平台访问能力cluster role的service account去部署这个POD。

转载自https://blog.csdn.net/cloudvtech

五、部署需要特殊权限的POD的例子

5.1 权限需求

POD里面的container需要以host network作为自己的网络环境并且需要privileged的系统权限

5.2 deployment的yaml文件如下

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: busybox-sa
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: busybox-sa
    spec:
      hostNetwork: true
      serviceAccount: sareader
      containers:
      - name: busybox-sa
        image: 200.222.0.243:5000/busybox-sa
        imagePullPolicy: Always
        securityContext:
          privileged: true 

如果使用sareader这个service account的默认能力去部署，会遇到如下错误：

5.3 将权限赋予sareader service account

oadm policy add-scc-to-user anyuid system:serviceaccount:hostnetwork-right:sareader
oadm policy add-scc-to-user privileged system:serviceaccount:hostnetwork-right:sareader
oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:hostnetwork-right:sareader

赋予的权限包括：

• 可以以root运行
• 具有最高权限(创建的POD可以使用host network)
• 可以读取这个Openshift cluster的信息

现在就能成功部署这个需要特殊权限的POD了：

转载自https://blog.csdn.net/cloudvtech