k8s和istio安全

1. 安全的三要素
   • 机密性，授权用户才可获取信息
   • 完整性，信息在输入和传输过程中，不被非法授权、篡改破坏
   • 可用性，用户正常的使用不被拒绝

使用非root用户运行容器

1. 在dockerfile中使用user命令切换成非root用户
   • 有的容器内部和外部的root用户是一个容易导致问题

FROM ubuntu
RUN user add xx
USER xx

user namespace和rootless container

1. user ns，依赖于user ns，任何容器内部用户都会映射到宿主机的非root用户，默认不开启
2. rootless container，指容器运行时以非root身份启动，在该配置下，即使容器被突破，在主机层面获得的用户权限也是非root的，确保了安全

集群的安全通信

1. k8s各个组件之间都通过安全进行通信，tls双向认证等

控制面

1. 认证
2. 授权
3. 配额

kubelet权限管理

1. kubelet可以对node和pod进行修改，使用noderestriction插件，可以限制kubelet的权限，防止kubelet获取kubeconfig

存储加密

1. k8s提供EncryptionConfiguration来设置需要加密的对象和算法，加密后发送给etcd

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguation
resources:
  - resources:
      - secrets
    providers:
      - identity: {}
      - aesgcm:
        keys:
          - name: key1
            secret# k8s和istio安全

1. 安全的三要素
    - 机密性，授权用户才可获取信息
    - 完整性，信息在输入和传输过程中，不被非法授权、篡改破坏
    - 可用性，用户正常的使用不被拒绝

### 使用非root用户运行容器

1. 在dockerfile中使用user命令切换成非root用户
    - 有的容器内部和外部的root用户是一个容易导致问题

FROM ubuntu
RUN user add xx
USER xx

### user namespace和rootless container

1. user ns，依赖于user ns，任何容器内部用户都会映射到宿主机的非root用户，默认不开启
2. rootless container，指容器运行时以非root身份启动，在该配置下，即使容器被突破，在主机层面获得的用户权限也是非root的，确保了安全

### 集群的安全通信

1. k8s各个组件之间都通过安全进行通信，tls双向认证等

### 控制面

1. 认证
2. 授权
3. 配额

### kubelet权限管理

1. kubelet可以对node和pod进行修改，使用noderestriction插件，可以限制kubelet的权限，防止kubelet获取kubeconfig

### 存储加密

1. k8s提供EncryptionConfiguration来设置需要加密的对象和算法，加密后发送给etcd

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguation
resources:

• resources:
  • secrets
    providers:
  • identity: {}
  • aesgcm:
    keys:
    • name: key1
      secret: xdkfs
    • name: key2
      secret: xxdf
  • aescbc:
    keys:
    • name: key1
      secret: xx
  • secretbox:
    keys:
    • name: k1
      secret: x
  • kms:
    name: mykmsPlugin
    endpoint: unix://xxx.sock
    cachesize: 100

### 实践

#### security context

pod中定义的安全上下文，用来描述允许他请求访问某个节点上特定的linux用户
1. container-level security context 对特定的容器使用
2. pod-levle security context 对pod内所有容器应用
    - 会影响volume（包括fsGroup和selinuxOptions），fsgroup即为挂载得volume的属组
3. pod security policies  集群内部的所有pod和volume
    - 一般情况下只会给管理员使用hostpath的权限
    - 如果要使用psp需要开启api server的admission plugin，先创建一个有全部权限的，给apiserver等，这种加上，不然apiserver会无法创建pod
    - 然后创建有限制的


项目|解释 |
---|---|
privileged| 运行特权容器 |
defaultAddCapabilities | 添加 Capabilities | 
requiredDropCapabilities | 删除的Capabilities|
volumes | 控制容器可以访问哪些volumes|
hostNetwork | host网络|
hostPorts | 允许host的port |
hostPID  | 使用host pid namespace|
hostIPC | 使用host  IPC namespace 是否可以跟主机的进行进行ipc通信 | 
seLInux | 配置selinux|
runAsUser | userID | 
supplementalGroups | |
fsGroup | volume 的group|
readOnlyRootFilesystem | 只读根文件系统| 

### taint

1. 一般推荐使用亲和性和反亲和性，使用污点进行隔离，会导致资源使用率的降低
    - 如果是高优的pod，想要占用cpu，可以使用–cpu-manager-policy=“static” 来绑定cpu
2. 增加taint  kubectl taint nodes node1 key=value:noschedule
3. 删除taint kubectl taint nodes node1 key:noschedule-
4. 设置容忍
    - operator的值为Exists，这时无需指定value
    - operator的值为Equal并且value相等
    - NoSchedule： 如果一个pod没有声明容忍这个Taint，则系统不会把该Pod调度到有这个Taint的node上
    - PreferNoSchedule：NoSchedule的软限制版本，如果一个Pod没有声明容忍这个Taint，则系统会尽量避免把这个pod调度到这一节点上去，但不是强制的。
    - NoExecute：定义pod的驱逐行为，以应对节点故障
5. 可以以租户为粒度添加Taint，节点彼此隔离，防止别人的应用出了漏洞，导致自己应用暴露

tolerations:

• key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

tolerations:

• key: "key"
  operator: "Exists"
  effect: "NoSchedule"