Kubernetes中限制仅内部访问的API端点

36次阅读

没有评论

问题描述

在Kubernetes中，有一个Java应用程序运行在一个Pod中（单个Docker容器），它具有“公共”端点和“内部”端点。

公共端点 /public 应该可以从公共互联网访问，并通过Ingress暴露出来。
内部端点 /internal 应该只能被Kubernetes集群中的其他Pod访问。

用户的问题是，是否有方法可以在“原生”的Kubernetes环境中限制对这些“内部”端点的访问？一种可能的方式是将公共端点列在Ingress中，但这似乎会变得混乱。用户还提到了类似Istio的工具是否允许基于策略的访问控制。

解决方案

在Kubernetes中，确保只有集群内部的Pod可以访问特定端点可以通过多种方式实现。下面将介绍两种常见的方法：

方案1：使用Ingress控制访问

一种简单的方法是使用Kubernetes的Ingress来控制访问。你可以将公共端点列在Ingress资源中，这样它们就可以通过公共互联网访问。然后，对于内部端点，你可以通过以下步骤来限制访问：

创建一个NetworkPolicy资源来定义允许访问内部端点的Pod之间的网络策略。
在NetworkPolicy中指定适当的podSelector和ingress规则，以控制哪些Pod可以访问内部端点。

以下是一个简单的示例NetworkPolicy资源，它允许带有特定标签的Pod访问/internal端点：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal-access
spec:
  podSelector:
    matchLabels:
      app: your-app-label
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: your-internal-app-label

在上面的示例中，podSelector中的标签应根据你的应用程序进行调整。这将确保只有带有your-internal-app-label标签的Pod可以访问/internal端点。

方案2：使用服务代理（如Istio）

另一种方法是使用服务代理，如Istio。Istio提供了丰富的流量管理和访问控制功能，可以让你更精细地控制应用程序间的通信。你可以使用Istio的DestinationRule和VirtualService来实现类似的访问控制。

以下是使用Istio实现访问控制的简单示例：

部署Istio到你的Kubernetes集群中。
创建一个DestinationRule资源来定义内部端点的流量策略：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: internal-destination
spec:
  host: your-internal-service-name
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

创建一个VirtualService资源来定义哪些Pod可以访问内部端点：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: internal-virtual-service
spec:
  hosts:
    - your-internal-service-name
  http:
    - route:
        - destination:
            host: your-internal-service-name
            subset: allowed-pods
      match:
        - sourceLabels:
            app: your-internal-app-label

在上面的示例中，你需要替换your-internal-service-name和your-internal-app-label为你的实际服务名称和标签。

请注意，Istio提供了更高级的策略和功能，可以更细致地控制流量和访问，以满足你的需求。