了解适用于 kubernetes 的 Istio AuthN 和 authz Pods

Understanding Istio AuthN and authz for kubernetes Pods

我对将 Istio 与 EKS 结合使用感到有些困惑。我们有 2 spring 个引导微服务,一个是 REST 服务提供者,另一个是消费者。我们想使用 Istio 实现 Authn 和 authz。

为此: 1. 在提供者服务方面:我有一个 VirtualService,一个目标规则(声明 TLS 模式对于传入流量应该是 ISTIO_MUTUAL),一个 AuthorizationPolicy,它基本上将客户端服务帐户列入白名单。我还有一个 AuthenticationPolicy 如下:

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: $APP_NAME-$FEATURE_NAME-authenticationpolicy
  namespace: $NAME_SPACE
spec:
  targets:
  - name: "$APP_NAME-$FEATURE_NAME"
  peers:
  - mtls:
      mode: STRICT

我的理解是此政策不允许任何非 mtls 的传入流量。

现在我怀疑如何配置我的客户端 pod 以发送所有传出的 mtls traffic.I 明白我必须创建一个 ServiceAccount,它使用 Authz 在提供商端列入白名单 Policy.I am在这里更关心我的客户端 pod,因为我不确定如何在 pod 级别启用 mtls。仅供参考,我不想在命名空间启用 mtls level.I 想使用 yaml 文件在 pod 级别启用它。

我对 Destination 规则、Authn 和 Authz 策略的使用的理解是否正确? Destination 规则、Authn 和 Authz 策略必须在服务提供商级别是否正确?客户端只需启用 MTLS 即可成功进行通信?我一直在浏览 Istio 文档,但这是我有疑问的地方

My understanding here is that this policy wont allow any incoming traffic which is non mtls.

没错,如果将 tls 模式设置为严格,则必须提供客户端证书,连接采用 TLS。


I am more concerned about my client pod here since I am not sure how to enable mtls at the pod level.

关于如何使这项工作有好处 article,特别是

部分

为两个服务之间的单个连接设置 mTLS

As Bookinfo is the Hello World of Istio, I am going to use this to explain how to set up mTLS from productpage to details service as shown in the above graph snippet.

There are two parts to this:

Install a Policy to tell Details that it wants to receive TLS traffic (only):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: details-receive-tls
spec:
  targets:
  - name: details
  peers:
  - mtls: {}
  1. Install a DestinationRule to tell clients (productpage) to talk TLS with details:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details-istio-mtls
spec:
  host: details.bookinfo.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

The following is a graphical representation of the involved services and where the previous two configuration documents apply.

Now when you look closely at the Policy above you will see and entry for the peer authentication

peers:
- mtls: {}

This means that TLS verification is strict and Istio (or rather the Envoy proxy in the pod) requires TLS traffic and a valid certificate. We can pass a flag to get permissive mode:

peers:
- mtls: 
    mode: PERMISSIVE

Is it correct that Destination rule, Authn and Authz policies have to be at the service provider level?

据我所知是的。

And the client just has to enable MTLS for the communication to work successfully?

我不确定,因为 MTLS 在网格内部工作,这取决于您的应用程序要求。


I want to do it at the pod level using a yaml file.

关于身份验证有 link 到 istio documentation,其中包括

另一个来自 github

或者您可以扩展网关的定义以支持双向 TLS。通过删除其密码并创建一个新密码来更改入口网关的凭据。服务器使用 CA 证书来验证其客户端,我们必须使用名称 cacert 来持有 CA 证书。您可以使用 cert-manager 生成客户端证书。


我找到了一些可能有用的教程,请查看。


如果您还有其他问题,请告诉我。

谢谢JT97.This我已经实现了

1) 对于身份验证,我已经为必须启用 MTLS 的传入请求实施了 Istio STRICT 身份验证策略。 Citadel 应该负责识别客户和服务提供商是否是他们声称的基于他们的证书的人。

2) 对于授权,我在客户端创建了一个服务帐户,并在服务器端添加了一个授权策略,以仅将那些我想使用我的 REST 资源的服务帐户列入白名单( PUT POST 等)

3) 我配置不同的一件事是目标规则。理想情况下,它应该在客户端,客户端说我正在声明我的提供者目标的目标规则是 this.What 我已经在提供者端声明了目标规则,以便它被传达给它的 Istio 网格ISTIO_MUTUAL 已准备就绪。在我看来,在提供者端声明目标规则没有任何区别。

4.) 我已经在命名空间 level.Have 中声明了目标规则,以便现在测试来自命名空间之外但在网格内的客户端。