系列：7、 Kubernetes 安全性

Kubernetes 安全性

我们将讨论 Kubernetes 安全性。 当我们在使用 Kubernetes 时，出于安全原因，我们有时会希望限制网络的访问或限制某些用户查看或运行某些命令等。

为此，我们必须使用不同的 Kubernetes 概念。

1、Network Policy（网络策略）

如果我们想限制来自或去往 Pod 的网络流量，我们需要定义一个 NetworkPolicy。

例如，如果我们想限制特定端口（比如 80 ）到我们的 nginx Pod 的流量 以及 如果我们想限制来自 nginx 端口（比如 8080 ）的流量，我们需要分别定义 Ingress 和 Egress 定义。 网络策略与带有标签的 Pod 相匹配。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nginx-network-policy
spec:
  podSelector:
    matchLabels:
      role: lb
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    ports:
    - protocol: TCP
      port: 8080

因此，此 NetworkPolicy 将应用于任何具有标签“role:lb”、限制 80 端口流量和 8080 端口流量的 Pod。

2、RBAC

Role-based access control（基于角色控制）是一种根据组织内个人用户的角色来调节对计算机或网络资源的访问的方法。

想象一下，在您的公司中，您有 50 人在 IT 部门工作，分为开发人员、测试人员和 DevOps。如果某些资源仅适用于 DevOps 人员（例如控制平面资源，因此开发人员和测试人员不会在这些资源上犯任何错误）并且该资源不应该对其他角色可见，那么我们可以通过定义 RBAC 来限制他们的访问。

我们可以定义一个角色或集群角色。

该角色仅适用于特定的命名空间。

顾名思义，ClusterRole 是集群范围的，并且它是非命名空间的。

因此，如果您需要对特定命名空间进行访问控制，请定义角色，不定义 ClusterRole。

创建角色后，我们必须根据需要和/或使用情况将它们绑定到 RoleBinding 或 ClusterRoleBinding。

应该在“verb”参数上提供用户/角色可能被允许的操作，该参数可以是下面列出的任何一个：

[get, list, watch, create, update, patch, delete]

请注意，Kubernetes 建议使用服务帐户（非人类帐户尝试进行身份验证），因此我们也必须创建服务帐户。

RBAC 可以定义为命令式和声明式。

出于学习目的，让我们创建上面提到的 3 个不同的角色，开发人员、测试人员和管理员。 开发人员将有权获取、列出和更新“developers”命名空间中的 Deployment 和 Pod，测试人员将有权列出“testers”命名空间中的 Pod，DevOps 将有权列出集群范围内的所有 Pod .

让我们从创建一个名为“developers”的命名空间开始：

kubectl create namespace developers

然后让我们使用命令式方法创建角色开发者：

kubectl create role dev-role --verb=get,list,create --resource=deployments,pods -n developers

用声明的方式创建，如下：

rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: developers
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods","deployments"]
  verbs: ["get", "list", "create"]

现在，如果我们想对单个用户使用它，我们将只为一个用户“ege”创建一个角色绑定：

这只是为了向您展示它会如何做。 但正如前面所提到的，Kubernetes 建议使用服务帐户，这将仅适用于用户“ege”，但实际上，我们不希望它仅适用于用户，而是适用于整个角色。 所以我们需要为此创建一个服务帐户：

kubectl create serviceaccount dev-sa -n developers

注意： Role 和 RoleBinding 应该在它们将被使用的特定命名空间上创建，但服务帐户可以在不同的命名空间上。

现在让我们再次将我们的角色开发者与创建的服务帐户绑定。

kubectl create rolebinding dev-sa-rb --role=dev-role --serviceaccount=developers:dev-sa

如上所示，当我们与服务帐户绑定时，我们首先编写命名空间，然后编写服务帐户的名称，如开发人员：dev-sa。

dev-sa.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-sa-rb
  namespace: developers
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: developers
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

下面继续创建test角色以及进行角色绑定

创建命名空间：

kubectl create namespace testers

现在让我们在“testers”命名空间中创建对 Pod 具有“list”权限的角色

kubectl create role tester-role --verb=list --resource=pods -n testers

创建testers的服务账号：

kubectl create serviceaccount tester-sa

kubectl create rolebinding tester-rb --role=tester-role --serviceaccount=testers:tester-sa -n testers

为 devops 创建集群角色：

kubectl create clusterrole devops-role --verb=list --resource=pods

给devops创建服务账号：

kubectl create serviceaccount devops-sa

查询现有角色：

kubectl get roles

默认空间内无角色

kubectl get roles -n developers

kubectl get roles -n testers

产看角色详细信息：

kubectl describe role dev-role -n developers

核查访问权限：

答案是yes，因为我们是自己集群的管理员。 要检查其他用户，我们需要添加“–as

kubectl auth can-i delete deployments --as tester-sa

该用户无相关权限。

3、Security Context（安全上下文）

安全上下文定义 Pod 或容器的权限和访问控制设置。

当我们想以特定用户身份运行 Pod 或 Container 时，我们会使用安全上下文。 所以我们可以通过添加安全上下文来定义运行 Pod 的用户。

路径是“.spec.securityContext”。

样例 YAML 文件：

pod-security-context.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

创建pod：

kubectl apply -f pod-security-context.yaml 

进入pod内：

kubectl exec -it security-context-demo  -- sh

我们可以在容器级别定义安全上下文。 请注意，容器级别的安全上下文将覆盖 Pod 级别。 例如：

pod-overide-sc.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 2000
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      runAsUser: 2000

创建pod：

kubectl  apply -f pod-overide-sc.yaml

查看用户：

kubectl exec -it busybox -- sh

可以看到用户是2000

系列：1、Kubernetes 简介

系列：2、创建Kubernetes集群

系列：3、Kubectl 的使用

系列：4.1、Kubernetes 对象

系列：4.2、Kubernetes 工作负载

系列：4.3、Kubernetes 服务

系列：4.4、Kubernetes 存储

系列：4.5、Kubernetes 配置对象

系列：5、Kubernetes中的调度

系列：6、Kubernetes 的升级与部署策略

系列：7、 Kubernetes 安全性（本文）

系列：8、部署一个全栈应用