是否可以用Istio代理替换Cloud SQL代理? [英] Is it possible to replace Cloud SQL proxy with Istio proxy?

问题描述

当前，我正在使用Cloud代理作为辅助工具连接到Postgres Cloud SQL数据库.但是，在使用Istio时，它会引入自己的小车，从而导致吊舱中有两个代理.因此，我可以使用Istio来建立加密连接吗?

基本上，可以使用Istio连接到外部IP

这也应该是可能的配置用于配置TLS的DestinationRule.

也可以创建客户端证书用于Cloud SQL .

可能是相同的问题: PostgreSQL的Nginx TLS终止

所以我最终得到了类似的东西

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-db
spec:
  hosts:
    - external-db
  ports:
    - number: 5432
      name: postgres
      protocol: TLS
  location: MESH_EXTERNAL
  resolution: STATIC
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: external-db
spec:
  host: external-db
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/client-cert.pem
      privateKey: /etc/certs/client-key.pem
      caCertificates: /etc/certs/server-ca.pem

---
apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  clusterIP: None
  ports:
    - protocol: TCP
      port: 5432
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-db
subsets:
  - addresses:
      - ip: 10.171.48.3
    ports:
      - port: 5432

并在豆荚中

sidecar.istio.io/userVolumeMount: '[{"name":"cert", "mountPath":"/etc/certs", "readonly":true}]'
sidecar.istio.io/userVolume: '[{"name":"cert", "secret":{"secretName":"cert"}}]'

但是，服务器拒绝连接.所以问题是，这种设置是否可能有效?甚至有意义吗?

解决方案

似乎Postgres使用了应用程序级协议协商，因此在这种情况下不能使用Istio/Envoy:

https://github.com/envoyproxy/envoy/issues/10942 https://github.com/envoyproxy/envoy/issues/9577#issuecomment- 606943362

Currently I am using Cloud proxy to connect to a Postgres Cloud SQL database as a sidecar. When using Istio, however it introduces its own sidecar, which lead to the result that there are two proxies in the pod. So I thougth, can the encrypted connection not also established using Istio?

Basically, it is possible to connect to an external IP using Istio.

It should also be possible to configure a DestinationRule which configures TLS.

And it also be possible to create Client certificates for Cloud SQL.

EDIT: might be the same problem: NGINX TLS termination for PostgreSQL

So I ended up with something like

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-db
spec:
  hosts:
    - external-db
  ports:
    - number: 5432
      name: postgres
      protocol: TLS
  location: MESH_EXTERNAL
  resolution: STATIC
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: external-db
spec:
  host: external-db
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/client-cert.pem
      privateKey: /etc/certs/client-key.pem
      caCertificates: /etc/certs/server-ca.pem

---
apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  clusterIP: None
  ports:
    - protocol: TCP
      port: 5432
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-db
subsets:
  - addresses:
      - ip: 10.171.48.3
    ports:
      - port: 5432

and in the pod with

sidecar.istio.io/userVolumeMount: '[{"name":"cert", "mountPath":"/etc/certs", "readonly":true}]'
sidecar.istio.io/userVolume: '[{"name":"cert", "secret":{"secretName":"cert"}}]'

However, the server rejects the connection. So the question is, can this setup possibly work? And does it even make any sense?

解决方案

It seems that Postgres uses application-level protocol negotation, so Istio/Envoy cannot be used in that case:

https://github.com/envoyproxy/envoy/issues/10942 https://github.com/envoyproxy/envoy/issues/9577#issuecomment-606943362

这篇关于是否可以用Istio代理替换Cloud SQL代理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！