k8s服务如何限制访问

K8s服务可以通过使用网络策略（Network Policies）、Ingress控制器、RBAC（角色访问控制）和Service Mesh等方式来限制访问。其中，网络策略是最常用且有效的一种方式，详细描述如下：网络策略允许你定义哪些Pod可以与其他Pod通信，基于标签的选择器来实现精细粒度的访问控制。这种方法不仅可以限制流量的来源和去向，还可以指定允许的端口和协议。通过配置网络策略，可以确保只有授权的服务和Pod能够相互通信，从而增强集群的安全性。

一、网络策略

网络策略（Network Policies）是Kubernetes中一种强大的访问控制工具。它允许管理员定义Pod间通信的规则，确保只有经过授权的Pod和服务能够相互访问。网络策略的定义基于Kubernetes的对象模型，使用YAML文件进行配置。它们依赖于网络插件，如Calico、Cilium或Weave Net等来实现实际的网络隔离和流量控制。

网络策略的核心概念包括Pod选择器（Pod Selector）和策略类型（Policy Type）。Pod选择器用于指定策略应用于哪些Pod，而策略类型则定义了允许的流量方向（入站或出站）。例如，创建一个网络策略来限制某个命名空间中的所有Pod只能接受来自特定标签的流量：

这种策略确保只有具有role: frontend标签的Pod能够访问role: backend标签的Pod，从而实现了精细粒度的访问控制。

二、Ingress控制器

Ingress控制器是Kubernetes中的另一个关键组件，用于管理集群内外的HTTP和HTTPS流量。通过配置Ingress资源，可以定义特定的路由规则，从而控制哪些外部请求可以访问内部服务。

Ingress控制器通常与反向代理（如NGINX、Traefik或Envoy）一起使用。这些代理可以解析Ingress规则，并根据配置将流量路由到适当的服务。例如，通过配置Ingress资源，可以限制特定的路径或子域只有特定的客户端能够访问：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: limited-access namespace: my-namespace spec: rules: - host: restricted.example.com http: paths: - path: /secure pathType: Prefix backend: service: name: secure-service port: number: 80

这种配置确保只有通过restricted.example.com/secure路径的请求才能访问secure-service，从而实现基于域名和路径的访问控制。

此外，Ingress控制器还支持TLS终止、身份验证和授权等高级功能，使得它成为管理外部访问的利器。

三、RBAC（角色访问控制）

RBAC（Role-Based Access Control）是Kubernetes中的一种授权机制，允许管理员基于角色和权限来控制用户和服务账户的操作权限。通过配置RBAC策略，可以限制哪些用户或服务账户能够创建、修改或删除特定的资源，从而提高集群的安全性。

RBAC策略由角色（Role）和角色绑定（RoleBinding）组成。角色定义了一组权限，而角色绑定则将角色分配给特定的用户或服务账户。以下是一个示例，展示如何创建一个限制访问特定命名空间的角色：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: my-namespace name: restricted-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: bind-restricted-role namespace: my-namespace subjects: - kind: User name: john.doe apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: restricted-role apiGroup: rbac.authorization.k8s.io

这种配置确保用户john.doe只能在my-namespace命名空间中获取和列出Pod，而不能进行其他操作。这种细粒度的权限控制有助于防止非授权操作，增强集群的安全性。

四、Service Mesh

Service Mesh是一种用于管理微服务间通信的基础设施层。它提供了服务发现、负载均衡、故障恢复、指标收集和分布式追踪等功能。通过使用Service Mesh，如Istio或Linkerd，可以实现更高级的访问控制和安全策略。

Service Mesh的核心组件包括数据平面和控制平面。数据平面负责处理实际的服务间通信，而控制平面则管理和配置数据平面的行为。通过配置Service Mesh，可以实现微服务间的零信任安全模型，确保只有经过验证和授权的服务能够相互通信。

例如，通过Istio，可以定义策略来限制特定服务只能从特定的命名空间或标签的服务接收请求：

apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: restrict-access namespace: my-namespace spec: selector: matchLabels: app: my-service rules: - from: - source: namespaces: ["trusted-namespace"] principals: ["*"]

这种配置确保只有来自trusted-namespace命名空间的请求能够访问my-service，从而实现了更高级别的安全控制。

五、Pod安全策略（Pod Security Policies）

Pod安全策略（Pod Security Policies，PSP）是一种用于控制Pod安全配置的机制。它允许管理员定义一组规则，限制Pod的创建和运行行为，从而提高集群的安全性。

PSP可以控制Pod的特权级别、卷类型、运行用户和组、网络策略等。通过配置PSP，可以确保只有符合安全要求的Pod才能在集群中运行。例如，创建一个PSP来限制Pod只能使用特定类型的卷和非特权用户：

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted-psp spec: privileged: false volumes: - "configMap" - "secret" runAsUser: rule: "MustRunAsNonRoot" seLinux: rule: "RunAsAny"

这种配置确保Pod只能使用configMap和secret类型的卷，并且必须以非特权用户身份运行，从而提高了集群的安全性。

六、Node限制

在Kubernetes中，节点限制是一种控制资源分配和访问的机制。通过配置节点选择器（Node Selectors）、污点和容忍度（Taints and Tolerations）等，可以限制Pod调度到特定的节点，从而实现资源隔离和安全控制。

节点选择器允许管理员指定Pod只能调度到具有特定标签的节点。例如，创建一个Pod调度策略，限制其只能运行在具有disktype: ssd标签的节点上：

apiVersion: v1 kind: Pod metadata: name: restricted-pod spec: containers: - name: my-container image: nginx nodeSelector: disktype: ssd

这种配置确保Pod只能调度到具有disktype: ssd标签的节点，从而实现了资源隔离和访问控制。污点和容忍度则允许管理员标记节点，使其不适合运行特定类型的Pod，除非Pod明确声明可以容忍这些污点。例如，创建一个污点和容忍度配置，限制Pod只能运行在特定的节点上：

apiVersion: v1 kind: Pod metadata: name: tolerant-pod spec: containers: - name: my-container image: nginx tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule"

这种配置确保Pod只能调度到具有特定污点的节点，从而实现了资源隔离和访问控制。

七、Network Policies和Service Mesh联合使用

网络策略和Service Mesh是Kubernetes中实现访问控制的两种主要机制。通过联合使用这两种工具，可以实现更高级别的安全控制和访问限制。

网络策略用于控制Pod间的流量，而Service Mesh则提供了更高级的流量管理和安全功能。通过配置网络策略和Service Mesh，可以实现微服务间的零信任安全模型，确保只有经过验证和授权的服务能够相互通信。

例如，通过配置网络策略和Istio，可以实现以下访问控制策略：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: restrict-access namespace: my-namespace spec: podSelector: matchLabels: role: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend --- apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: restrict-access namespace: my-namespace spec: selector: matchLabels: app: backend rules: - from: - source: namespaces: ["trusted-namespace"] principals: ["*"]

这种配置确保只有来自trusted-namespace命名空间的请求能够访问backend服务，从而实现了更高级别的安全控制。

八、总结与最佳实践

为了确保Kubernetes集群的安全性和访问控制，管理员应综合使用上述多种机制，包括网络策略、Ingress控制器、RBAC、Service Mesh、Pod安全策略和节点限制等。每种机制都有其独特的优势和适用场景，通过合理配置和组合使用，可以实现全面的访问控制和安全保护。

最佳实践包括：定期审查和更新访问控制策略，确保其符合最新的安全要求和业务需求；使用最小权限原则，仅授予用户和服务账户必要的权限，防止过度授权；监控和日志记录，定期检查集群的访问日志和监控数据，及时发现和处理潜在的安全问题；自动化配置管理，使用工具如Helm或Kustomize来管理和部署Kubernetes资源，确保配置的一致性和可重复性；安全教育和培训，确保团队成员了解和掌握Kubernetes安全最佳实践，提高整体的安全意识。

通过综合使用上述机制和最佳实践，可以有效地限制Kubernetes服务的访问，确保集群的安全性和稳定性。

FAQs: 如何限制 K8s 服务的访问

1. 如何使用 Kubernetes 网络策略来限制服务的访问？

在 Kubernetes 中，网络策略（Network Policies）是控制 Pod 间通信的重要工具。通过定义网络策略，您可以限制哪些 Pod 可以访问您的服务。这些策略基于标签选择器和端口定义，用于控制入站和出站流量。首先，您需要确保您的集群支持网络策略（如使用 Calico 或其他支持网络策略的 CNI 插件）。

定义网络策略时，可以使用以下几个步骤：

创建网络策略 YAML 文件：在该文件中，您可以指定允许或拒绝的流量规则。例如，您可以定义只允许来自某些标签的 Pod 访问特定的服务。
应用网络策略：使用 kubectl apply -f <策略文件>.yaml 命令将网络策略应用到您的集群。
验证策略效果：通过检查 Pod 的日志和使用工具（如 kubectl exec）来确保策略如预期般生效。

示例网络策略 YAML 文件如下：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-pods
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 80

此策略仅允许具有标签 role: backend 的 Pod 访问标签为 role: frontend 的 Pod 的 80 端口。

2. 如何通过 Kubernetes Ingress 控制服务的访问权限？

Kubernetes 的 Ingress 资源允许您管理集群内服务的外部访问。通过配置 Ingress 规则，您可以指定哪些外部请求可以访问特定的服务。Ingress 还支持基于路径和主机名的路由规则，使得流量控制更加灵活。

创建和管理 Ingress 时，需要考虑以下几点：

定义 Ingress 规则：创建 Ingress 资源时，您可以定义路由规则、主机名和路径。您还可以设置 TLS 加密以确保数据传输的安全性。
配置 Ingress 控制器：Ingress 规则通常依赖于 Ingress 控制器（如 Nginx、Traefik），这些控制器负责将外部请求路由到正确的服务。
设置访问策略：通过配置 Ingress 规则中的 annotations，您可以应用访问限制，如 IP 白名单或其他安全策略。

示例 Ingress 配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.1.0/24"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: example-tls

上述配置中，Ingress 规则仅允许来自 192.168.1.0/24 子网的 IP 地址访问 example.com 的服务。

3. 如何利用 Kubernetes RBAC 进行服务访问控制？

Kubernetes 的角色访问控制（RBAC）允许您细化对集群资源的访问权限，包括对服务的访问。通过创建和绑定角色（Role）和角色绑定（RoleBinding），您可以定义哪些用户或服务账户可以访问哪些资源。

RBAC 的配置步骤如下：

定义角色：创建角色资源时，您可以指定允许访问的资源类型和操作。例如，您可以创建一个角色，仅允许某些用户读取服务信息。
创建角色绑定：将角色绑定到特定的用户或服务账户。角色绑定定义了哪些用户或服务账户可以使用特定的角色。
验证权限：确保角色和角色绑定按预期工作，可以通过使用 kubectl auth can-i 命令测试访问权限。

示例角色和角色绑定 YAML 文件如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: service-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-services
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: service-reader
  apiGroup: rbac.authorization.k8s.io

上述配置为 alice 用户提供了对 default 命名空间中服务的只读访问权限。

关于 GitLab 的更多内容，可以查看官网文档：
官网地址： https://gitlab.cn
文档地址： https://docs.gitlab.cn
论坛地址： https://forum.gitlab.cn

原创文章，作者：xiaoxiao，如若转载，请注明出处：https://devops.gitlab.cn/archives/49282