Tls error secret is not supplied by sds

Bug description There is very rare issue: sometimes istio-sidecar doesn't get certs from control panel For example we update deployment with 2 replicas and one replica works fine but second did...

Bug description
There is very rare issue:
sometimes istio-sidecar doesn’t get certs from control panel
For example we update deployment with 2 replicas and one replica works fine but second didn’t get certs and return error "upstream_transport_failure_reason":"TLS error: Secret is not supplied by SDS"

Affected product area (please put an X in all that apply)

[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Affected features (please put an X in all that apply)

[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane

Expected behavior
logs from pod which started normal

{"level":"info","time":"2020-08-13T15:18:25.767413Z","msg":"Using user-configured CA istio-pilot.istio-system.svc:15012"}
{"level":"info","time":"2020-08-13T15:18:25.767427Z","msg":"istiod uses self-issued certificate"}
{"level":"info","time":"2020-08-13T15:18:25.767484Z","msg":"the CA cert of istiod is: -----BEGIN CERTIFICATE-----nMIIC3jCCAcagAwIBAgIRAIVxCB1L92l5peSp9C9WbYwwDQYJKoZIhvcNAQELBQAwnGDEWMBQGA1UEChMNY2x1c3Rlci5sb2NhbDAeFw0xOTA2MzAxOTIxNDFaFw0yOTA2nMjcxOTIxNDFaMBgxFjAUBgNVBAoTDWNsdXN0ZXIubG9jYWwwggEiMA0GCSqGSIb3nDQEBAQUAA4IBDwAwggEKAoIBAQDNmVplAF/dfUvWOyCJ+W6gCGK0AqnE+odKL5CUnLUF9FbHs2vvxHunGFmh5/TsbcOObWxFzQAb3RN8UtaQ6kQd52qdxY6A2Dqg0rLfMnRbpkPrmP+eLsB4cfKqPbZs6YeRErhCa316WeQ9BPKG6O66QWCRu98RnCxKm4H91Un0V1ileOb6aiGHLSiW7NI0vd7NyrAKrHlB7sPI/R7ezZFau2pNGmgWo0c5dlU84LBn09WVfjydfEbmmAyQAjVpea8HWNgIJMLZmehRUEu0WrKuXlmeRTSY3cn4OozjR0kWnkgZEUhPhfu3Qokjio1fI9ElxE65/VE+SUWuuLVO5bEAkewiHAgMBAAGjIzAhMA4GnA1UdDwEB/wQEAwICBDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBnAQBFI/5tgv/pqw/a+zbPjGomdXvG8op1ZcqkH0EnrfBSwPJKIInF7H1ZFBs+hZl4n+s7fiOf797iGmzX/Q6TdV4JWW+xM1f1+gC3rOPIKtx114lj8iTbsOz7iQyYIM/v8nddJUsclVeaAkgI6kILmB7aidFkXAytu91aMuNnLPlU5nTSKkPKa78QC6yXdMsll0nI9i8j07h6UvpisyUsMIa2k6nMozPGFjGs6rt/z+o6vwiB4NBGwHRak23fRPWmeBBnvKSULkLdQOCKasPiwIXm0J3JlHLaWIsAJzPM57d6fKGmDqiR6I1Snzk3R2J61gSan1jvXX62dag2Tmhm7DEcCvkDLn-----END CERTIFICATE-----n"}
{"level":"info","time":"2020-08-13T15:18:25.767651Z","msg":"parsed scheme: """}
{"level":"info","time":"2020-08-13T15:18:25.767666Z","msg":"scheme "" not registered, fallback to default scheme"}
{"level":"info","time":"2020-08-13T15:18:25.767691Z","msg":"ccResolverWrapper: sending update to cc: {[{istio-pilot.istio-system.svc:15012  <nil> 0 <nil>}] <nil> <nil>}"}
{"level":"info","time":"2020-08-13T15:18:25.767698Z","msg":"ClientConn switching balancer to "pick_first""}
{"level":"info","time":"2020-08-13T15:18:25.767960Z","msg":"pickfirstBalancer: HandleSubConnStateChange: 0xc0003e9900, {CONNECTING <nil>}"}
{"level":"info","time":"2020-08-13T15:18:25.779104Z","msg":"pickfirstBalancer: HandleSubConnStateChange: 0xc0003e9900, {READY <nil>}"}
{"level":"info","time":"2020-08-13T15:18:25.808050Z","scope":"sds","msg":"SDS gRPC server for workload UDS starts, listening on "/etc/istio/proxy/SDS" n"}
{"level":"info","time":"2020-08-13T15:18:25.808137Z","scope":"sds","msg":"Start SDS grpc server"}
{"level":"info","time":"2020-08-13T15:18:25.808285Z","msg":"PilotSAN []string{"istiod.istio-system.svc"}"}
{"level":"info","time":"2020-08-13T15:18:25.808310Z","msg":"Starting proxy agent"}
{"level":"info","time":"2020-08-13T15:18:25.808395Z","msg":"Opening status port 15020n"}
{"level":"info","time":"2020-08-13T15:18:25.808414Z","msg":"Received new config, creating new Envoy epoch 0"}
{"level":"info","time":"2020-08-13T15:18:25.808607Z","msg":"Epoch 0 starting"}
{"level":"info","time":"2020-08-13T15:18:25.814621Z","msg":"Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster kernel.cxxxx-kernel-stable --service-node sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local --max-obj-name-len 189 --local-address-ip-version v4 --log-format [Envoy (Epoch 0)] [%Y-%m-%d %T.%e][%t][%l][%n] %v -l warning --component-log-level misc:error --concurrency 2]"}
[Envoy (Epoch 0)] [2020-08-13 15:18:25.874][21][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, no healthy upstream
[Envoy (Epoch 0)] [2020-08-13 15:18:25.874][21][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:54] Unable to establish new stream
{"level":"info","time":"2020-08-13T15:18:25.881474Z","scope":"sds","msg":"node:sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-1 resource:default new connection"}
{"level":"info","time":"2020-08-13T15:18:26.020897Z","scope":"cache","msg":"Root cert has changed, start rotating root cert for SDS clients"}
{"level":"info","time":"2020-08-13T15:18:26.021124Z","scope":"sds","msg":"node:sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-1 resource:default pushed key/cert pair to proxy"}
{"level":"info","time":"2020-08-13T15:18:26.021151Z","scope":"sds","msg":"node:sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-1 resource:default pushed secret"}
{"level":"info","time":"2020-08-13T15:18:26.316567Z","scope":"sds","msg":"node:sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-2 resource:ROOTCA new connection"}
{"level":"info","time":"2020-08-13T15:18:26.316818Z","scope":"sds","msg":"node:sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-2 resource:ROOTCA pushed root cert to proxy"}
{"level":"info","time":"2020-08-13T15:18:26.316847Z","scope":"sds","msg":"node:sidecar~10.160.73.140~kernel-84bb4fdf68-vlbjh.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-2 resource:ROOTCA pushed secret"}
{"level":"info","time":"2020-08-13T15:18:27.399741Z","msg":"Envoy proxy is ready"}
WARN [src/istio/mixerclient/report_batch.cc:110] Mixer Report failed with: UNAVAILABLE:Cluster not available
{"protocol":"-","upstream_service_time":"-","upstream_local_address":"10.160.73.140:60388","duration":"60507","upstream_transport_failure_reason":"-","route_name":"-","downstream_local_address":"1.1.1.252:443","user_agent":"-","response_code":"0","response_flags":"-","start_time":"2020-08-13T15:18:28.411Z","method":"-","request_id":"-","upstream_host":"3.123.252.252:443","x_forwarded_for":"-","requested_server_name":"secretsmanager.eu-central-1.amazonaws.com","bytes_received":"2065","istio_policy_status":"-","bytes_sent":"20900","upstream_cluster":"outbound|443||*.amazonaws.com","downstream_remote_address":"10.160.73.140:60386","authority":"-","path":"-"}

and envoy has all certs

{
 "certificates": [
  {
   "ca_cert": [
    {
     "path": "./var/run/secrets/istio/root-cert.pem",
     "serial_number": "8571081d4bf76979a5e4a9f42f566d8c",
     "subject_alt_names": [],
     "days_until_expiration": "3240",
     "valid_from": "2019-06-30T19:21:41Z",
     "expiration_time": "2029-06-27T19:21:41Z"
    }
   ],
   "cert_chain": [
    {
     "path": "u003cinlineu003e",
     "serial_number": "aa989111e09156a8279b4975342671a3",
     "subject_alt_names": [
      {
       "uri": "spiffe://cluster.local/ns/xxxxx-kernel-stable/sa/default"
      }
     ],
     "days_until_expiration": "0",
     "valid_from": "2020-08-13T15:18:26Z",
     "expiration_time": "2020-08-14T15:18:26Z"
    }
   ]
  },
  {
   "ca_cert": [
    {
     "path": "u003cinlineu003e",
     "serial_number": "8571081d4bf76979a5e4a9f42f566d8c",
     "subject_alt_names": [],
     "days_until_expiration": "3240",
     "valid_from": "2019-06-30T19:21:41Z",
     "expiration_time": "2029-06-27T19:21:41Z"
    }
   ],
   "cert_chain": [
    {
     "path": "u003cinlineu003e",
     "serial_number": "aa989111e09156a8279b4975342671a3",
     "subject_alt_names": [
      {
       "uri": "spiffe://cluster.local/ns/xxxx-kernel-stable/sa/default"
      }
     ],
     "days_until_expiration": "0",
     "valid_from": "2020-08-13T15:18:26Z",
     "expiration_time": "2020-08-14T15:18:26Z"
    }
   ]

Steps to reproduce the bug
I don’t know
just proxy logs it

{"level":"info","time":"2020-08-13T15:18:24.491833Z","msg":"Using user-configured CA istio-pilot.istio-system.svc:15012"}
{"level":"info","time":"2020-08-13T15:18:24.491837Z","msg":"istiod uses self-issued certificate"}
{"level":"info","time":"2020-08-13T15:18:24.491875Z","msg":"the CA cert of istiod is: -----BEGIN CERTIFICATE-----nMIIC3jCCAcagAwIBAgIRAIVxCB1L92l5peSp9C9WbYwwDQYJKoZIhvcNAQELBQAwnGDEWMBQGA1UEChMNY2x1c3Rlci5sb2NhbDAeFw0xOTA2MzAxOTIxNDFaFw0yOTA2nMjcxOTIxNDFaMBgxFjAUBgNVBAoTDWNsdXN0ZXIubG9jYWwwggEiMA0GCSqGSIb3nDQEBAQUAA4IBDwAwggEKAoIBAQDNmVplAF/dfUvWOyCJ+W6gCGK0AqnE+odKL5CUnLUF9FbHs2vvxHunGFmh5/TsbcOObWxFzQAb3RN8UtaQ6kQd52qdxY6A2Dqg0rLfMnRbpkPrmP+eLsB4cfKqPbZs6YeRErhCa316WeQ9BPKG6O66QWCRu98RnCxKm4H91Un0V1ileOb6aiGHLSiW7NI0vd7NyrAKrHlB7sPI/R7ezZFau2pNGmgWo0c5dlU84LBn09WVfjydfEbmmAyQAjVpea8HWNgIJMLZmehRUEu0WrKuXlmeRTSY3cn4OozjR0kWnkgZEUhPhfu3Qokjio1fI9ElxE65/VE+SUWuuLVO5bEAkewiHAgMBAAGjIzAhMA4GnA1UdDwEB/wQEAwICBDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBnAQBFI/5tgv/pqw/a+zbPjGomdXvG8op1ZcqkH0EnrfBSwPJKIInF7H1ZFBs+hZl4n+s7fiOf797iGmzX/Q6TdV4JWW+xM1f1+gC3rOPIKtx114lj8iTbsOz7iQyYIM/v8nddJUsclVeaAkgI6kILmB7aidFkXAytu91aMuNnLPlU5nTSKkPKa78QC6yXdMsll0nI9i8j07h6UvpisyUsMIa2k6nMozPGFjGs6rt/z+o6vwiB4NBGwHRak23fRPWmeBBnvKSULkLdQOCKasPiwIXm0J3JlHLaWIsAJzPM57d6fKGmDqiR6I1Snzk3R2J61gSan1jvXX62dag2Tmhm7DEcCvkDLn-----END CERTIFICATE-----n"}
{"level":"info","time":"2020-08-13T15:18:24.491976Z","msg":"parsed scheme: """}
{"level":"info","time":"2020-08-13T15:18:24.491985Z","msg":"scheme "" not registered, fallback to default scheme"}
{"level":"info","time":"2020-08-13T15:18:24.491999Z","msg":"ccResolverWrapper: sending update to cc: {[{istio-pilot.istio-system.svc:15012  <nil> 0 <nil>}] <nil> <nil>}"}
{"level":"info","time":"2020-08-13T15:18:24.492004Z","msg":"ClientConn switching balancer to "pick_first""}
{"level":"info","time":"2020-08-13T15:18:24.492138Z","msg":"pickfirstBalancer: HandleSubConnStateChange: 0xc00048a760, {CONNECTING <nil>}"}
{"level":"info","time":"2020-08-13T15:18:24.499062Z","msg":"pickfirstBalancer: HandleSubConnStateChange: 0xc00048a760, {READY <nil>}"}
{"level":"info","time":"2020-08-13T15:18:24.524221Z","scope":"sds","msg":"SDS gRPC server for workload UDS starts, listening on "/etc/istio/proxy/SDS" n"}
{"level":"info","time":"2020-08-13T15:18:24.524290Z","scope":"sds","msg":"Start SDS grpc server"}
{"level":"info","time":"2020-08-13T15:18:24.524367Z","msg":"PilotSAN []string{"istiod.istio-system.svc"}"}
{"level":"info","time":"2020-08-13T15:18:24.524379Z","msg":"Starting proxy agent"}
{"level":"info","time":"2020-08-13T15:18:24.524435Z","msg":"Opening status port 15020n"}
{"level":"info","time":"2020-08-13T15:18:24.524467Z","msg":"Received new config, creating new Envoy epoch 0"}
{"level":"info","time":"2020-08-13T15:18:24.524534Z","msg":"Epoch 0 starting"}
{"level":"info","time":"2020-08-13T15:18:24.528823Z","msg":"Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster kernel.cxxxx-kernel-stable --service-node sidecar~10.160.86.22~kernel-84bb4fdf68-nskqd.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local --max-obj-name-len 189 --local-address-ip-version v4 --log-format [Envoy (Epoch 0)] [%Y-%m-%d %T.%e][%t][%l][%n] %v -l warning --component-log-level misc:error --concurrency 2]"}
[Envoy (Epoch 0)] [2020-08-13 15:18:24.571][25][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, no healthy upstream
[Envoy (Epoch 0)] [2020-08-13 15:18:24.571][25][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:54] Unable to establish new stream
{"level":"info","time":"2020-08-13T15:18:24.578476Z","scope":"sds","msg":"node:sidecar~10.160.86.22~kernel-84bb4fdf68-nskqd.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-1 resource:default new connection"}
{"level":"info","time":"2020-08-13T15:18:24.701750Z","scope":"cache","msg":"Root cert has changed, start rotating root cert for SDS clients"}
{"level":"info","time":"2020-08-13T15:18:24.701877Z","scope":"sds","msg":"node:sidecar~10.160.86.22~kernel-84bb4fdf68-nskqd.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-1 resource:default pushed key/cert pair to proxy"}
{"level":"info","time":"2020-08-13T15:18:24.701886Z","scope":"sds","msg":"node:sidecar~10.160.86.22~kernel-84bb4fdf68-nskqd.cxxxx-kernel-stable~cxxxx-kernel-stable.svc.cluster.local-1 resource:default pushed secret"}
{"level":"info","time":"2020-08-13T15:18:26.400750Z","msg":"Envoy proxy is NOT ready: Get http://127.0.0.1:15000/stats?usedonly&filter=^(cluster_manager.cds|listener_manager.lds).(update_success|update_rejected)$: net/http: request canceled (Client.Timeout exceeded while awaiting headers)"}
{"level":"info","time":"2020-08-13T15:18:27.403033Z","msg":"Envoy proxy is ready"}
WARN [src/istio/mixerclient/report_batch.cc:110] Mixer Report failed with: UNAVAILABLE:Cluster not available
{"bytes_sent":"0","upstream_cluster":"outbound|13001||yyyy-api.capt-integration-yyyy-api-stable.svc.cluster.local","downstream_remote_address":"10.160.86.22:36124","authority":"yyyy-api.capt-integration-yyyy-api-stable.svc.cluster.local:13001","path":"/yyyy.transaction.v1.TransactionAPI/CreateCardTransaction","protocol":"HTTP/2","upstream_service_time":"-","upstream_local_address":"-","duration":"67","upstream_transport_failure_reason":"TLS error: Secret is not supplied by SDS","route_name":"default","downstream_local_address":"172.20.249.175:13001","user_agent":"grpc-go/1.30.0","response_code":"200","response_flags":"UF,URX","start_time":"2020-08-13T15:19:24.633Z","method":"POST","request_id":"0094c8c4-4f80-b3c5-69c7-818246ed5020","upstream_host":"10.160.77.25:13001","x_forwarded_for":"-","requested_server_name":"-","bytes_received":"494","istio_policy_status":"-"}

And in his cert only exist this

   {
 "certificates": [
  {
   "ca_cert": [
    {
     "path": "./var/run/secrets/istio/root-cert.pem",
     "serial_number": "8571081d4bf76979a5e4a9f42f566d8c",
     "subject_alt_names": [],
     "days_until_expiration": "3240",
     "valid_from": "2019-06-30T19:21:41Z",
     "expiration_time": "2029-06-27T19:21:41Z"
    }
   ],
   "cert_chain": [
    {
     "path": "u003cinlineu003e",
     "serial_number": "a201e37403a587e0eccb9e8668bac7a0",
     "subject_alt_names": [
      {
       "uri": "spiffe://cluster.local/ns/xxxx-kernel-stable/sa/default"
      }
     ],
     "days_until_expiration": "0",
     "valid_from": "2020-08-13T15:18:24Z",
     "expiration_time": "2020-08-14T15:18:24Z"
    }
   ]
  }
 ]
}

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)

istioctl version --remote
client version: 1.5.8
ingressgateway version: 1.5.6
policy version: 1.5.6
waf-gateway-private version: 
waf-gateway-public version: 
waf-gateway-solaris version: 
waf-gateway-vpn version: 
pilot version: 1.5.6
pilot version: 1.5.6
pilot version: 1.5.6
pilot version: 1.5.6
pilot version: 1.5.6
data plane version: 1.5.6 (834 proxies)

How was Istio installed?
istioctl manifest apply

Environment where bug was observed (cloud vendor, OS, etc)
EKS

Источник

Hello,

we are running Istio v1.9.5 in our cluster.

I receive the following error when trying to curl our backend over MTLS

upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: Secret is not supplied by SDS

Here are the logs that I receive in the ingress-gateway

<html>
<body>
<!--StartFragment-->

{"protocol":"HTTP/2","route_name":null,"method":"GET","upstream_transport_failure_reason":"TLS error: Secret is not supplied by SDS","x_forwarded_for":"192.168.0.69","requested_server_name":"test.emea.dam.corpintra.net","bytes_received":0,"request_id":"fdbf831b-3a07-4813-a52c-055ade55e517","connection_termination_details":null,"start_time":"2021-08-27T08:29:06.302Z","upstream_service_time":null,"duration":42,"path":"/int/v2/videos","response_flags":"UF,URX","response_code_details":"upstream_reset_before_response_started{connection_failure,TLS_error:_Secret_is_not_supplied_by_SDS}","response_code":503,"upstream_local_address":null,"upstream_host":"185.192.78.237:443","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36","downstream_local_address":"192.168.131.17:8443","downstream_remote_address":"192.168.0.69:10500","upstream_cluster":"outbound|443||some-site.com","bytes_sent":159,"authority":"some-site.com"}
--

We
have setup the following DestinationRule in order to enforce MTLS towards our backend:

spec:
  host: some-site.com
  trafficPolicy:
    connectionPool:
      http:
        h2UpgradePolicy: DO_NOT_UPGRADE
        idleTimeout: 10s
      tcp:
        connectTimeout: 2s
        maxConnections: 1800
    portLevelSettings:
    - port:
        number: 443
      tls:
        caCertificates: /etc/istio/ingressgateway-client-ca-certs-corpintra/cacert
        clientCertificate: /etc/istio/ingressgateway-client-acme-certs-mutual/cert
        mode: MUTUAL
        privateKey: /etc/istio/ingressgateway-client-acme-certs-mutual/key
        sni: some-site.com

All files are available in the Ingressgateway and apparently when running

istioctl pc s <ingressgateway_pod_name>

I do not see any errors or warnings regarding our certificates or ca-certificates. All certificates are valid according to istioctl pc s

I also do not see any errors when the ingressgateway pods are restarting, the SDS PUSH seems to be working with no issues at all.

Here is a snippet of our logs when the ingressgateway is starting:

2021-08-27T08:20:57.769452Z     info    ads     ADS: new connection for node:router~192.168.131.115~emea-test-mgceeu4m6zlzei-697f4687dd-wb92f.istio-system~istio-system.svc.cluster.local-1
2021-08-27T08:20:57.770460Z     info    ads     ADS: new connection for node:router~192.168.131.115~emea-test-mgceeu4m6zlzei-697f4687dd-wb92f.istio-system~istio-system.svc.cluster.local-2
2021-08-27T08:20:57.770930Z     info    cache   adding watcher for file certificate /etc/istio/ingressgateway-client-acme-certs-mutual/cert
2021-08-27T08:20:57.770965Z     info    cache   read certificate from file      resource=file-cert:/etc/istio/ingressgateway-client-acme-certs-mutual/cert~/etc/istio/ingressgateway-client-acme-certs-mutual/key
2021-08-27T08:20:57.772341Z     info    sds     SDS: PUSH       resource=file-cert:/etc/istio/ingressgateway-client-acme-certs-mutual/cert~/etc/istio/ingressgateway-client-acme-certs-mutual/key
2021-08-27T08:20:57.772878Z     info    cache   adding watcher for file certificate /etc/istio/ingressgateway-client-ca-certs-corpintra/cacert
2021-08-27T08:20:57.772913Z     info    cache   read certificate from file      resource=file-root:/etc/istio/ingressgateway-client-ca-certs-corpintra/cacert
2021-08-27T08:20:57.773195Z     info    sds     SDS: PUSH       resource=file-root:/etc/istio/ingressgateway-client-ca-certs-corpintra/cacert
2021-08-27T08:20:57.963251Z     info    envoy upstream  cm init: initializing secondary clusters
2021-08-27T08:20:58.061122Z     info    cache   Root cert has changed, start rotating root cert
2021-08-27T08:20:58.061162Z     info    ads     XDS: Incremental Pushing:0 ConnectedEndpoints:2 Version:
2021-08-27T08:20:58.061183Z     info    cache   generated new workload certificate      latency=3.995577876s ttl=23h59m58.938825743s
2021-08-27T08:20:58.065168Z     info    ads     ADS: new connection for node:router~192.168.131.115~emea-test-mgceeu4m6zlzei-697f4687dd-wb92f.istio-system~istio-system.svc.cluster.local-3
2021-08-27T08:20:58.065295Z     info    cache   returned workload certificate from cache        ttl=23h59m58.934712123s
2021-08-27T08:20:58.065327Z     info    sds     SDS: PUSH       resource=default
2021-08-27T08:20:58.161384Z     info    ads     ADS: new connection for node:router~192.168.131.115~emea-test-mgceeu4m6zlzei-697f4687dd-wb92f.istio-system~istio-system.svc.cluster.local-4
2021-08-27T08:20:58.161627Z     info    sds     SDS: PUSH       resource=ROOTCA
2021-08-27T08:20:58.370369Z     info    envoy upstream  cm init: all clusters initialized
2021-08-27T08:20:58.370569Z     info    envoy main      all clusters initialized. initializing init manager
2021-08-27T08:20:58.466231Z     info    envoy tracing   instantiating a new tracer: envoy.tracers.zipkin
2021-08-27T08:20:58.564027Z     info    envoy upstream  lds: add/update listener '0.0.0.0_8443'
2021-08-27T08:20:58.566547Z     info    envoy upstream  lds: add/update listener '0.0.0.0_8080'
2021-08-27T08:20:58.670739Z     info    envoy config    all dependencies initialized. starting workers
2021-08-27T08:20:58.879877Z     info    Initialization took 5.515558752s
2021-08-27T08:20:58.879911Z     info    Envoy proxy is ready

Any ideas why that error might occur?

Источник

Соответствующая часть журналов с istio 1.2.0 в ingressgateway:

[2019-06-20 08:14:03.329][18][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:86] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[2019-06-20 08:14:05.116][18][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:86] gRPC config stream closed: 2, no credential token is found
[2019-06-20T08:14:04.282Z] "GET / HTTP/2" 503 UF,URX "-" "TLS error: Secret is not supplied by SDS" 0 91 63 - "10.0.96.20" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" "29ff51bb-e6f2-44ca-8457-1bc61521f43f" "REDACTED" "10.0.93.98:80" outbound|80|v1|REDACTED.svc.cluster.local - 10.0.92.103:443 10.0.96.20:49298 REDACTED

Во время даунгрейда в логах было следующее:

2019-06-20T08:14:15.925698Z     info    watchFileEvents: "/etc/certs/cert-chain.pem": MODIFY|ATTRIB
2019-06-20T08:14:15.925768Z     info    watchFileEvents: "/etc/certs/cert-chain.pem": DELETE
2019-06-20T08:14:15.925975Z     info    watchFileEvents: "/etc/certs/root-cert.pem": MODIFY|ATTRIB
2019-06-20T08:14:15.925990Z     info    watchFileEvents: "/etc/certs/root-cert.pem": DELETE
2019-06-20T08:14:15.926205Z     info    watchFileEvents: "/etc/certs/key.pem": MODIFY|ATTRIB
2019-06-20T08:14:15.926218Z     info    watchFileEvents: "/etc/certs/key.pem": DELETE
2019-06-20T08:14:25.925902Z     info    watchFileEvents: notifying
2019-06-20T08:14:25.926130Z     info    Received new config, resetting budget
2019-06-20T08:14:25.926140Z     info    Reconciling retry (budget 10)
2019-06-20T08:14:25.926164Z     info    Epoch 1 starting
2019-06-20T08:14:25.927145Z     info    Envoy command: [-c /etc/istio/proxy/envoy-rev1.json --restart-epoch 1 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster auth-proxy-ingressgateway --service-node router~10.0.92.103~auth-proxy-ingressgateway-5cf658ddb6-7zx7c.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]

И снова начал работать.

РЕДАКТИРОВАТЬ:
Я сделал обновление в двух разных кластерах разработки и получил тот же результат. Не могу играть с ним слишком много, потому что люди полагаются на него :/

@myidpt можешь проверить? Я не могу выяснить, где создается «Секрет, не предоставленный SDS», и это кажется специфичным для SDS.

Это самая важная часть журнала [2019-06-20 08:14:05.116][18][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:86] gRPC config stream closed: 2, no credential token is found

@MrBlaise , можете ли вы прокомментировать, как вы установили 1.1.8 (какие параметры) и как вы обновились (с какими параметрами)?

Режим helm template или helm upgrade
вставьте helm version , пожалуйста

Спасибо @sdake , это будет очень полезно для отладки.

@MrBlaise Не могли бы вы показать нам дамп конфигурации шлюза ingres? Ошибка 503 звучит так, будто входной шлюз не может связаться с внутренней вспомогательной машиной. Было бы полезно, если бы мы могли проверить, есть ли в конфигурации динамического кластера конфигурация SDS или путь монтирования файла для сертификатов.

@MrBlaise Если в конфигурации динамического кластера есть конфигурация SDS, не могли бы вы также показать нам, работает ли агент Citadel на каждом узле?

Я предоставлю более подробную информацию, когда буду в офисе, но я использовал шаблон helm для установки istio. У меня есть два ingressgateways, один действует как край (он разрешает только внутренним сотрудникам) и перенаправляет запросы другому внутри страны.

Из журнала
«»GET / HTTP/2» 503 UF,URX «-» «Ошибка TLS: секрет не предоставлен SDS» 0 91 63 — «10.0.96.20» «Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/ 537.36 (KHTML, например Gecko) Chrome/74.0.3729.169 Safari/537.36» «29ff51bb-e6f2-44ca-8457-1bc61521f43f» «УДАЛЕНО» «10.0.93.98:80″ исходящий |80|v1|УДАЛЕНО.svc.cluster.local — 10.0.92.103:443 10.0.96.20:49298 УДАЛЕНО»
Это сбой между входным шлюзом и вспомогательной машиной рабочей нагрузки.
Согласно https://www.envoyproxy.io/docs/envoy/latest/configuration/access_log ,
UF: сбой восходящего соединения в дополнение к коду ответа 503.

Я предоставлю более подробную информацию, когда буду в офисе, но я использовал шаблон helm для установки istio. У меня есть два ingressgateways, один действует как край (он разрешает только внутренним сотрудникам) и перенаправляет запросы другому внутри страны.

Спасибо за ответ. Это 503 от пограничного входного шлюза? Если да, то пограничный входной шлюз пытается перенаправить запрос основному входному шлюзу через mTLS. Затем вам нужно использовать подход с монтированием файлов, чтобы предоставить ключ/сертификат для конфигурации кластера пограничного входного шлюза и конфигурации прослушивателя основного входного шлюза. Возможно, обновление включает SDS для конфигурации кластера пограничного входного шлюза.

Край сначала обычно перенаправляет на экземпляр apache, который выполняет аутентификацию oauth, и эта служба перенаправляет его на другой вход. Но после обновления весь процесс останавливается на краю, сервер apache никогда не вызывается. С 1.1.8 он отлично работает, используя sds на краю :/

Таким образом, сбой происходит между краем и сервером apache. Дамп конфигурации через $ curl 127.0.0.1:15000/config_dump поможет. Похоже, что край пытается связаться с apache через Cluster «исходящий | 80 | v1 | REDACTED.svc.cluster.local»

Мои значения руля следующие:

global:
  # This needs to be turned off when using sds.
  # It might be fixed in istio 1.2
  # The reason it fails is because it needs the mounted secret to work and sds disables that
  controlPlaneSecurityEnabled: false

  mtls:
    # Default setting for service-to-service mtls. Can be set explicitly using
    # destination rules or service annotations.
    enabled: true

  sds:
    enabled: true
    udsPath: "unix:/var/run/sds/uds_path"
    useNormalJwt: true

  disablePolicyChecks: false

  proxy:
    accessLogFile: "/dev/stdout"

sidecarInjectorWebhook:
  enabled: true
  # If true, webhook or istioctl injector will rewrite PodSpec for liveness
  # health check to redirect request to sidecar. This makes liveness check work
  # even when mTLS is enabled.
  rewriteAppHTTPProbe: true

mixer:
  policy:
    enabled: true
    autoscaleMax: 2
  telemetry:
    enabled: true
    autoscaleMax: 2

pilot:
  autoscaleMax: 2

# Nodeagent will utilise the Secret Discovery Service (SDS) to enable mutual TLS without kubernetes secrets
nodeagent:
  enabled: true
  image: node-agent-k8s
  env:
    CA_PROVIDER: "Citadel"
    CA_ADDR: "istio-citadel:8060"
    VALID_TOKEN: true

# Enabling sds will allow us to utilize cert-manager with let's encrypt certs
gateways:
  istio-ingressgateway:
    enabled: true
    sds:
      enabled: true
    type: ClusterIP
    autoscaleMax: 3
    ports:
    - name: status-port
      port: 15020
      protocol: TCP
      targetPort: 15020
    - name: http2
      port: 80
      protocol: TCP
      targetPort: 80
    - name: https
      port: 443
      protocol: TCP
      targetPort: 443
    - name: tcp
      port: 31400
      protocol: TCP
      targetPort: 31400
    - name: https-kiali
      port: 15029
      protocol: TCP
      targetPort: 15029
    - name: https-prometheus
      port: 15030
      protocol: TCP
      targetPort: 15030
    - name: https-grafana
      port: 15031
      protocol: TCP
      targetPort: 15031
    - name: https-tracing
      port: 15032
      protocol: TCP
      targetPort: 15032
    - name: tls
      port: 15443
      protocol: TCP
      targetPort: 15443
  auth-proxy-ingressgateway:
    enabled: true
    sds:
      image: node-agent-k8s
      enabled: true
    labels:
      app: auth-proxy-ingressgateway
      istio: auth-proxy-ingressgateway
    autoscaleEnabled: true
    replicaCount: 1
    autoscaleMin: 1
    autoscaleMax: 3
    cpu:
      targetAverageUtilization: 80
    type: LoadBalancer #change to NodePort, ClusterIP or LoadBalancer if need be
    loadBalancerIP: REDACTED
    ports:
    - name: status-port
      port: 15020
      protocol: TCP
      targetPort: 15020
    - name: http2
      port: 80
      protocol: TCP
      targetPort: 80
    - name: https
      port: 443
      protocol: TCP
      targetPort: 443
    - name: tcp
      port: 31400
      protocol: TCP
      targetPort: 31400
    - name: https-kiali
      port: 15029
      protocol: TCP
      targetPort: 15029
    - name: https-prometheus
      port: 15030
      protocol: TCP
      targetPort: 15030
    - name: https-grafana
      port: 15031
      protocol: TCP
      targetPort: 15031
    - name: https-tracing
      port: 15032
      protocol: TCP
      targetPort: 15032
    - name: tls
      port: 15443
      protocol: TCP
      targetPort: 15443

certmanager:
  enabled: true

# Enables tracing using jaeger
tracing:
  enabled: true
  ingress:
    enabled: false

grafana:
  enabled: true

# A service to visualize the service mesh
kiali:
  enabled: true
  tag: v0.20
  dashboard:
    jaegerURL: "http://localhost:16686/jaeger"
    grafanaURL: "http://localhost:3000"

Я только что понял эту часть, которую я прокомментировал:

  # This needs to be turned off when using sds.
  # It might be fixed in istio 1.2
  # The reason it fails is because it needs the mounted secret to work and sds disables that
  controlPlaneSecurityEnabled: false

Может быть что-то интересное или вообще не связанное.

@MrBlaise у нас есть коляска istio перед сервером apache? Я предполагаю, что нет, и если это так, то трафик между пограничным входом и сервером apache должен быть простым текстом, верно?

@wattli У него установлен istio sidecar, поэтому он должен иметь mTLS.

@MrBlaise Спасибо за информацию. У меня есть несколько вопросов.
(1) Используете ли вы SDS рабочей нагрузки и входной SDS как для 1.2.0, так и для 1.1.8? Из значений helm global.sds.enabled=true (это для рабочей нагрузки SDS), gateways.istio-ingressgateway.sds.enabled=true(входной SDS) и gateways.auth-proxy-ingressgateway.sds.enabled=true .
(2) Какой из них является пограничным входным шлюзом, auth-proxy-ingressgateway или istio-ingressgateway? Насколько я понимаю, шлюз auth-proxy-ingressgateway является граничным и перенаправляет запрос в кластер «outbound|80|v1|auth-proxy.authproxy.svc.cluster.local», который также использует SDS для обработки входящего соединения.
(3) Не могли бы вы использовать kubectl get pods -n istio-system -o wide и проверить идентификатор узла для каждого запущенного модуля? Должен быть агент узла в том же узле, где работает сервер apache, и другой агент узла, где работает шлюз auth-proxy-ingressgateway. Не могли бы вы их найти и проверить логи, возможно в логах есть ошибки.
(4) Я также заметил, что некоторые конфигурации кластера используют SDS, но не ожидается, что они будут использовать SDS. Например,
исходящий|9091||istio-policy.istio-system.svc.cluster.local
исходящий |9090||prometheus.istio-system.svc.cluster.local
исходящий|9901||istio-galley.istio-system.svc.cluster.local
исходящий|14267||jaeger-collector.istio-system.svc.cluster.local
исходящий|15010||istio-pilot.istio-system.svc.cluster.local
outbound|15014||istio-citadel.istio-system.svc.cluster.local (это очень сбивает с толку, прокси не разговаривает с Citadel, но в этом конфиге настроен SDS)
При controlPlaneSecurityEnabled: false все компоненты istio-system используют секреты монтирования файлов.
@quanjielin
(5) Было бы неплохо, если бы вы предоставили полный шаблон управления вашей установкой.

@JimmyCYJ

1, я использую одни и те же значения helm для 1.1.8 и 1.2.0, единственное, что я сделал, это проверил тег 1.2.0 в репозитории git и с помощью шаблона helm сгенерировал файлы манифеста и применил их с помощью kubectl. Я использую как рабочую нагрузку, так и входной sds.

2, я использую эту архитектуру для кластеров разработки, и она выглядит следующим образом:

client -> auth-proxy-ingressgateway -> auth-proxy -> (internal call) istio-ingressgateway -> some_application

auth-proxy-ingressgateway -> использование sds с возможностью шифрования сгенерированных сертификатов
auth-proxy -> сервер apache, который аутентифицирует сотрудников с помощью auth0 и перенаправляет запросы в случае успеха, в противном случае отклоняет их
istio-ingressgateway -> этот вход защищен с помощью jwt, который предоставляет auth-proxy (это только внутренний, он не имеет внешнего IP-адреса, поэтому не использует sds для https)

3, я попытаюсь получить эту информацию, когда буду в офисе. Я вернул все кластеры на 1.1.8, чтобы убедиться, что они работают, и чтобы увидеть журналы, я обновил его снова на пару минут, а затем обратно.

4. Извините, я еще не знаком с istio, поэтому не знаю, в чем может быть проблема.

  1. Я сгенерирую его в ближайшее время и отправлю сюда вкратце.

@MrBlaise Спасибо за информацию. У меня есть несколько вопросов.
(1) Используете ли вы SDS рабочей нагрузки и входной SDS как для 1.2.0, так и для 1.1.8? Из значений helm global.sds.enabled=true (это для рабочей нагрузки SDS), gateways.istio-ingressgateway.sds.enabled=true(входной SDS) и gateways.auth-proxy-ingressgateway.sds.enabled=true .
(2) Какой из них является пограничным входным шлюзом, auth-proxy-ingressgateway или istio-ingressgateway? Насколько я понимаю, шлюз auth-proxy-ingressgateway является граничным и перенаправляет запрос в кластер «outbound|80|v1|auth-proxy.authproxy.svc.cluster.local», который также использует SDS для обработки входящего соединения.
(3) Не могли бы вы использовать kubectl get pods -n istio-system -o wide и проверить идентификатор узла для каждого запущенного модуля? Должен быть агент узла в том же узле, где работает сервер apache, и другой агент узла, где работает шлюз auth-proxy-ingressgateway. Не могли бы вы их найти и проверить логи, возможно в логах есть ошибки.
(4) Я также заметил, что некоторые конфигурации кластера используют SDS, но не ожидается, что они будут использовать SDS. Например,
исходящий|9091||istio-policy.istio-system.svc.cluster.local
исходящий |9090||prometheus.istio-system.svc.cluster.local
исходящий|9901||istio-galley.istio-system.svc.cluster.local
исходящий|14267||jaeger-collector.istio-system.svc.cluster.local
исходящий|15010||istio-pilot.istio-system.svc.cluster.local
outbound|15014||istio-citadel.istio-system.svc.cluster.local (это очень сбивает с толку, прокси не разговаривает с Citadel, но в этом конфиге настроен SDS)
При controlPlaneSecurityEnabled: false все компоненты istio-system используют секреты монтирования файлов.
@quanjielin

Не имеет значения, является ли значение controlPlaneSecurityEnabled истинным или ложным, на сегодняшний день мы поддерживаем только монтирование файлов для пилотной версии. Полный шаблон шлема определенно будет полезен.

(5) Было бы неплохо, если бы вы предоставили полный шаблон управления вашей установкой.

@MrBlaise Спасибо! Еще один вопрос: если у вас есть возможность обновиться с 1.1.8 до 1.2.0, не могли бы вы также проверить модули и убедиться, что агенты узла (для рабочей нагрузки SDS) обновлены вместе с другими компонентами? Вы можете проверить с помощью $ kubectl -n istio-system descriptionа поле «Изображение:» показывает, какую версию выпуска он использует. Даже с вашим текущим развертыванием, поскольку вы уже понизили развертывание до 1.1.8, не могли бы вы использовать $kubectl get pods -n istio-system, проверить столбец «AGE» и посмотреть, живут ли модули агента узла дольше, чем другие компоненты?

В настоящее время с 1.1.8:

kubectl -n istio-system describe daemonsets istio-nodeagent

Name:           istio-nodeagent
Selector:       app=nodeagent,chart=nodeagent,heritage=Tiller,istio=nodeagent,release=istio
Node-Selector:  <none>
Labels:         app=nodeagent
                chart=nodeagent
                heritage=Tiller
                istio=nodeagent
                release=istio
Annotations:    deprecated.daemonset.template.generation: 6
                kubectl.kubernetes.io/last-applied-configuration:
                  {"apiVersion":"extensions/v1beta1","kind":"DaemonSet","metadata":{"annotations":{},"labels":{"app":"nodeagent","chart":"nodeagent","herita...
Desired Number of Nodes Scheduled: 3
Current Number of Nodes Scheduled: 3
Number of Nodes Scheduled with Up-to-date Pods: 0
Number of Nodes Scheduled with Available Pods: 3
Number of Nodes Misscheduled: 0
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:           app=nodeagent
                    chart=nodeagent
                    heritage=Tiller
                    istio=nodeagent
                    release=istio
  Service Account:  istio-nodeagent-service-account
  Containers:
   nodeagent:
    Image:      gcr.io/istio-release/node-agent-k8s:release-1.1-latest-daily
    Port:       <none>
    Host Port:  <none>
    Environment:
      CA_ADDR:       istio-citadel:8060
      CA_PROVIDER:   Citadel
      Plugins:       
      VALID_TOKEN:   true
      Trust_Domain:  
    Mounts:
      /var/run/sds from sdsudspath (rw)
  Volumes:
   sdsudspath:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/sds
    HostPathType:  
Events:            <none>

kubectl get pods -n istio-system

NAME                                                         READY   STATUS      RESTARTS   AGE
auth-proxy-ingressgateway-5cf658ddb6-c76h2                   2/2     Running     0          11h
certmanager-cc589c6fc-m9hwt                                  1/1     Running     0          23d
grafana-77b49c55db-5l9dt                                     1/1     Running     0          11h
istio-citadel-67547bbc88-l6tvf                               1/1     Running     0          11h
istio-cleanup-secrets-release-1.1-latest-daily-xfbxd         0/1     Completed   0          34h
istio-cleanup-secrets-release-1.2-latest-daily-h7x8b         0/1     Completed   0          35h
istio-galley-7fd894b657-g6s2h                                1/1     Running     0          11h
istio-grafana-post-install-release-1.1-latest-daily-v24lb    0/1     Completed   0          34h
istio-grafana-post-install-release-1.2-latest-daily-rd4xm    0/1     Completed   0          35h
istio-ingressgateway-5fb58d6b88-d299s                        2/2     Running     0          11h
istio-init-crd-10-lxszp                                      0/1     Completed   0          35h
istio-init-crd-11-rv5fv                                      0/1     Completed   0          35h
istio-init-crd-12-88jgl                                      0/1     Completed   0          35h
istio-init-crd-certmanager-10-vx6r4                          0/1     Completed   0          35h
istio-init-crd-certmanager-11-rvfcc                          0/1     Completed   0          35h
istio-nodeagent-kmjfn                                        1/1     Running     0          23d
istio-nodeagent-ppf97                                        1/1     Running     0          23d
istio-nodeagent-zsjjd                                        1/1     Running     0          23d
istio-pilot-54fdd796b5-nvd85                                 2/2     Running     0          11h
istio-policy-6488f9f564-d5nf4                                2/2     Running     0          11h
istio-security-post-install-release-1.1-latest-daily-xc6qc   0/1     Completed   0          34h
istio-security-post-install-release-1.2-latest-daily-x5d2p   0/1     Completed   0          35h
istio-sidecar-injector-659f55dcfc-r2hvc                      1/1     Running     0          11h
istio-telemetry-5f5fd8844b-hxwtf                             2/2     Running     0          11h
istio-tracing-595796cf54-cgnz5                               1/1     Running     0          23d
kiali-775b4557dc-pbgkv                                       1/1     Running     0          11h
prometheus-5fffdf8848-wk6rm                                  1/1     Running     0          11h

Хм, может быть, это так, похоже, что агенты узлов очень старые, поэтому они, должно быть, вообще не изменились во время обновления или понижения версии. @JimmyCYJ

@MrBlaise Кажется, что агент узла никогда не обновляется и не понижается. Сейчас им 23 года.
И агент узла — это gcr.io/istio-release/node-agent-k8s:release-1.1-latest-daily, поэтому это не 1.1.8 или 1.2.0. Это также сбивает с толку.

Не могли бы вы сделать еще одну вещь? Запустите $ kubectl -n istio-system description pods istio-ingressgateway-5fb58d6b88-d299s и $ kubectl -n istio-system description pods auth-proxy-ingressgateway-5cf658ddb6-c76h2, и давайте посмотрим, какая версия агента узла используется для шлюзов.

kubectl -n istio-system описать модули istio-ingressgateway-5fb58d6b88-d299s

Name:               istio-ingressgateway-5fb58d6b88-d299s
Namespace:          istio-system
Priority:           0
PriorityClassName:  <none>
Node:               gke-platform-platform-pool-1-964cd9e8-g887/10.0.96.20
Start Time:         Fri, 21 Jun 2019 09:45:03 +0200
Labels:             app=istio-ingressgateway
                    chart=gateways
                    heritage=Tiller
                    istio=ingressgateway
                    pod-template-hash=5fb58d6b88
                    release=istio
Annotations:        sidecar.istio.io/inject: false
Status:             Running
IP:                 10.0.93.176
Controlled By:      ReplicaSet/istio-ingressgateway-5fb58d6b88
Containers:
  ingress-sds:
    Container ID:   docker://14ab5428b35298c9f6cb8d528254bd1fd20cbc2ac2695f06a576e430366a8b41
    Image:          gcr.io/istio-release/node-agent-k8s:release-1.1-latest-daily
    Image ID:       docker-pullable://gcr.io/istio-release/node-agent-k8s<strong i="6">@sha256</strong>:cd0495b31ea8e63b15634143b30b67e5a94a00a74bb40235b57caca99cb05b39
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 21 Jun 2019 09:45:06 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  128Mi
    Environment:
      ENABLE_WORKLOAD_SDS:         false
      ENABLE_INGRESS_GATEWAY_SDS:  true
      INGRESS_GATEWAY_NAMESPACE:   istio-system (v1:metadata.namespace)
    Mounts:
      /var/run/ingress_gateway from ingressgatewaysdsudspath (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from istio-ingressgateway-service-account-token-z7hml (ro)
  istio-proxy:
    Container ID:  docker://05db8ad6ec72aacbb00dbffc51e30a96ecf78b2d2d9d54e04450099460e23db8
    Image:         gcr.io/istio-release/proxyv2:release-1.1-latest-daily
    Image ID:      docker-pullable://gcr.io/istio-release/proxyv2<strong i="7">@sha256</strong>:b3c1ec3c8e059a91df7b961088e795f77637cbabc382ade0fa8c4d139848a310
    Ports:         15020/TCP, 80/TCP, 443/TCP, 31400/TCP, 15029/TCP, 15030/TCP, 15031/TCP, 15032/TCP, 15443/TCP, 15090/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
    Args:
      proxy
      router
      --domain
      $(POD_NAMESPACE).svc.cluster.local
      --log_output_level=default:info
      --drainDuration
      45s
      --parentShutdownDuration
      1m0s
      --connectTimeout
      10s
      --serviceCluster
      istio-ingressgateway
      --zipkinAddress
      zipkin:9411
      --proxyAdminPort
      15000
      --statusPort
      15020
      --controlPlaneAuthPolicy
      NONE
      --discoveryAddress
      istio-pilot:15010
    State:          Running
      Started:      Fri, 21 Jun 2019 09:45:06 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:      100m
      memory:   128Mi
    Readiness:  http-get http://:15020/healthz/ready delay=1s timeout=1s period=2s #success=1 #failure=30
    Environment:
      POD_NAME:                     istio-ingressgateway-5fb58d6b88-d299s (v1:metadata.name)
      POD_NAMESPACE:                istio-system (v1:metadata.namespace)
      INSTANCE_IP:                   (v1:status.podIP)
      HOST_IP:                       (v1:status.hostIP)
      ISTIO_META_POD_NAME:          istio-ingressgateway-5fb58d6b88-d299s (v1:metadata.name)
      ISTIO_META_CONFIG_NAMESPACE:  istio-system (v1:metadata.namespace)
      ISTIO_META_USER_SDS:          true
      ISTIO_META_ROUTER_MODE:       sni-dnat
    Mounts:
      /etc/certs from istio-certs (ro)
      /etc/istio/ingressgateway-ca-certs from ingressgateway-ca-certs (ro)
      /etc/istio/ingressgateway-certs from ingressgateway-certs (ro)
      /var/run/ingress_gateway from ingressgatewaysdsudspath (rw)
      /var/run/sds/uds_path from sdsudspath (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from istio-ingressgateway-service-account-token-z7hml (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  ingressgatewaysdsudspath:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  sdsudspath:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/sds/uds_path
    HostPathType:  Socket
  istio-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  istio.istio-ingressgateway-service-account
    Optional:    true
  ingressgateway-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  istio-ingressgateway-certs
    Optional:    true
  ingressgateway-ca-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  istio-ingressgateway-ca-certs
    Optional:    true
  istio-ingressgateway-service-account-token-z7hml:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  istio-ingressgateway-service-account-token-z7hml
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

kubectl -n istio-system описать модули auth-proxy-ingressgateway-5cf658ddb6-c76h2

Name:               auth-proxy-ingressgateway-5cf658ddb6-c76h2
Namespace:          istio-system
Priority:           0
PriorityClassName:  <none>
Node:               gke-platform-platform-pool-1-964cd9e8-qhg9/10.0.96.19
Start Time:         Fri, 21 Jun 2019 09:45:02 +0200
Labels:             app=auth-proxy-ingressgateway
                    chart=gateways
                    heritage=Tiller
                    istio=auth-proxy-ingressgateway
                    pod-template-hash=5cf658ddb6
                    release=istio
Annotations:        sidecar.istio.io/inject: false
Status:             Running
IP:                 10.0.92.122
Controlled By:      ReplicaSet/auth-proxy-ingressgateway-5cf658ddb6
Containers:
  ingress-sds:
    Container ID:   docker://30b64e5723147cf3c35fd53931bf08958b2a38f3db1f23a35e38b5226717ae11
    Image:          gcr.io/istio-release/node-agent-k8s:release-1.1-latest-daily
    Image ID:       docker-pullable://gcr.io/istio-release/node-agent-k8s<strong i="6">@sha256</strong>:77a3febb6a00bf98f8230d2133be78914ff0e8adf71b587e3da28c0230a7abd5
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 21 Jun 2019 09:45:04 +0200
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:  10m
    Environment:
      ENABLE_WORKLOAD_SDS:         false
      ENABLE_INGRESS_GATEWAY_SDS:  true
      INGRESS_GATEWAY_NAMESPACE:   istio-system (v1:metadata.namespace)
    Mounts:
      /var/run/ingress_gateway from ingressgatewaysdsudspath (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from auth-proxy-ingressgateway-service-account-token-vjl7r (ro)
  istio-proxy:
    Container ID:  docker://24c700c0241f8444a4589ba89f1e64f1a4ce1062278e3f8773fee785315653e4
    Image:         gcr.io/istio-release/proxyv2:release-1.1-latest-daily
    Image ID:      docker-pullable://gcr.io/istio-release/proxyv2<strong i="7">@sha256</strong>:b3c1ec3c8e059a91df7b961088e795f77637cbabc382ade0fa8c4d139848a310
    Ports:         15020/TCP, 80/TCP, 443/TCP, 31400/TCP, 15029/TCP, 15030/TCP, 15031/TCP, 15032/TCP, 15443/TCP, 15090/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
    Args:
      proxy
      router
      --domain
      $(POD_NAMESPACE).svc.cluster.local
      --log_output_level=default:info
      --drainDuration
      45s
      --parentShutdownDuration
      1m0s
      --connectTimeout
      10s
      --serviceCluster
      auth-proxy-ingressgateway
      --zipkinAddress
      zipkin:9411
      --proxyAdminPort
      15000
      --statusPort
      15020
      --controlPlaneAuthPolicy
      NONE
      --discoveryAddress
      istio-pilot:15010
    State:          Running
      Started:      Fri, 21 Jun 2019 09:45:05 +0200
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:      10m
    Readiness:  http-get http://:15020/healthz/ready delay=1s timeout=1s period=2s #success=1 #failure=30
    Environment:
      POD_NAME:                     auth-proxy-ingressgateway-5cf658ddb6-c76h2 (v1:metadata.name)
      POD_NAMESPACE:                istio-system (v1:metadata.namespace)
      INSTANCE_IP:                   (v1:status.podIP)
      HOST_IP:                       (v1:status.hostIP)
      ISTIO_META_POD_NAME:          auth-proxy-ingressgateway-5cf658ddb6-c76h2 (v1:metadata.name)
      ISTIO_META_CONFIG_NAMESPACE:  istio-system (v1:metadata.namespace)
      ISTIO_META_USER_SDS:          true
    Mounts:
      /etc/certs from istio-certs (ro)
      /var/run/ingress_gateway from ingressgatewaysdsudspath (rw)
      /var/run/sds/uds_path from sdsudspath (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from auth-proxy-ingressgateway-service-account-token-vjl7r (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  ingressgatewaysdsudspath:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  sdsudspath:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/sds/uds_path
    HostPathType:  Socket
  istio-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  istio.auth-proxy-ingressgateway-service-account
    Optional:    true
  auth-proxy-ingressgateway-service-account-token-vjl7r:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  auth-proxy-ingressgateway-service-account-token-vjl7r
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

Что я делаю, так это клонирую репозиторий istio checkout 1.1.8 и запускаю шаблон helm с моими значениями:

git clone https://github.com/istio/istio
cd istio
git checkout 1.1.8
cd ..
helm template istio/install/kubernetes/helm/istio --name istio --namespace istio-system --values istio-config/istio_helm_values/istio/values_dev.yml | k apply -f -

ОБНОВИТЬ:

И проверяя вывод, он генерирует эти ежедневные теги изображений.
Для 1.1.8: выпуск-1.1-последний-ежедневно
Для 1.2.0: выпуск-1.2-последний-ежедневно

@MrBlaise Большое спасибо! Оба используют gcr.io/istio-release/node-agent-k8s:release-1.1-latest-daily, который не является стабильной версией 1.1.8. Это не выглядит правильным.

Из шаблона руля
1.1.8 использует все образы из выпуска 1.1-latest-daily (например, gcr.io/istio-release/proxy_init:release-1.1-latest-daily)
а 1.2.0 использует все изображения из выпуска 1.2-latest-daily.
@ваттли

У меня такое чувство, что я что-то неправильно понял и что мне не следует использовать теги github для установки istio.

ОБНОВИТЬ:

Да, загрузка tarball из раздела релиза создает правильные образы.

Это все еще странно, почему nodeagents не обновились, поскольку манифест helm явно генерирует для них разные образы, используя метод тега github.

Я пошел дальше и использовал архив 1.1.8 и применил изменения, все изменилось на правильный образ 1.1.8, кроме агентов узла, они все еще используют старый образ, даже если во время применения он был настроен.

Набор демонов показывает правильное изображение 1.1.8, но сами модули не изменились. Они на 1.1.7 со старой установки кажется.

ОБНОВИТЬ:

k get daemonsets -n istio-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
istio-nodeagent 3 3 3 0 3 <none> 23d

Это, вероятно, основная причина:

updateStrategy:
      type: OnDelete

Похоже, они не будут делать непрерывное обновление, мне нужно удалить их вручную.

Ладно, кластером никто не пользовался, поэтому я пошел дальше и

  • обновлен до 1.2.0 с помощью архива
  • удаленные агенты узла вручную

Это все равно не сработает

Мне пришлось воссоздать auth-proxy и все мои сервисы, чтобы у них была правильная коляска envoy.

И это РАБОТАЕТ!

РЕДАКТИРОВАТЬ:

Что было бы хорошим способом сделать подобное обновление на производстве с нулевым временем простоя. Похоже, мне нужно вручную удалить агенты узла, и до тех пор, пока край недоступен, мне нужно воссоздать все свои службы, чтобы край не возвращал 503.

@JimmyCYJ @ваттли

MrBlaise, спасибо за вашу помощь в расследовании, это ошибка, и мы скоро свяжемся с вами.

Это, вероятно, основная причина:

updateStrategy:
      type: OnDelete

Где ты нашел эту строчку?

Похоже, они не будут делать непрерывное обновление, мне нужно удалить их вручную.

@wattli Это было в выводе kubectl get daemonsets -n istio-system istio-nodeagent -o yaml

Спасибо за находку, это действительно проблема, мы вышлем исправление в ближайшее время.
@quanjielin

@quanjielin спасибо, что так быстро исправили. Можем ли мы оставить эту ошибку открытой, чтобы добавить сценарий SDS к нашим существующим тестам обновления?

@wattli @quanjielin @duderino Есть ли рекомендуемый способ или руководство по обновлению istio на кластере с включенным sds без простоев? В настоящее время даже с этим исправлением старые коляски будут отклонять любое соединение, и их необходимо перезапустить, чтобы получить новую версию, которая работает.

Я обновил кластер до версии 1.2.2, агенты узлов обновлены должным образом, но с включенным mtls мне все равно нужно перезапустить все мои модули, потому что старые боковые машины отклоняют запросы: / Модули без включенного mtls начали работать через минуту. или около того, но у них также были простои.

@MrBlaise, с какой версии вы обновились до 1.2.2?

Вы имели в виду, что при обновлении 1.1.8 -> 1.2.2 необходимо перезапустить модули? если да, то это ожидаемо, поскольку исправления в 1.1 (https://github.com/istio/istio/pull/15105) нет в 1.1.8.

Ясно спасибо. Это будет больно на производстве, но, по крайней мере, позже это не должно быть проблемой.

Я предпочитаю закрыть эту проблему и открыть новую с соответствующей темой/названием, чтобы отслеживать задачу создания сценария SDS для наших существующих тестов обновления.

@MrBlaise Просто дважды проверьте: вы включили SDS только на входном шлюзе или также на боковых компонентах рабочей нагрузки?

Спасибо @MrBlaise Используете ли вы SDS для своего производства?
Пожалуйста, взгляните на https://github.com/istio/istio/pull/15568#issuecomment -515146740.
Я также упоминал об этом в слабом канале. Мы обсудим это на завтрашнем заседании ТОС.
Пожалуйста, дайте нам знать, как PR повлияет на вас.

Была ли эта страница полезной?

0 / 5 — 0 рейтинги

Источник

I am trying to set up a cluster with Istio on it, where the SSL traffic gets terminated at the Ingress. I have deployed Istio with SDS and Mutual TLS. With the below yaml, I only get the error message upstream connect error or disconnect/reset before headers. reset reason: connection failure when accessing my cluster in the browser:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: default-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP
---
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx1
  name: nginx1
spec:
  containers:
  - image: nginx
    name: nginx
    resources: {}
    ports:
    - containerPort: 80
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}
---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx1
  name: nginx1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx1
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx1
spec:
  hosts:
  - "*"
  gateways:
  - istio-system/default-gateway
  http:
  - match:
    - uri:
        prefix: /nginx1
    route:
    - destination:
        port:
          number: 80
        host: nginx1.default.svc.cluster.local

The ingressgateway logs show the following TLS error:

[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:88] creating a new connection
[2019-07-09 09:07:24.907][29][debug][client] [external/envoy/source/common/http/codec_client.cc:26] [C4759] connecting
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:702] [C4759] connecting to 100.200.1.59:80
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:711] [C4759] connection in progress
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/conn_pool_base.cc:20] queueing request due to no available connections
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:550] [C4759] connected
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C4759] handshake error: 2
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C4759] handshake error: 1
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:201] [C4759] TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:188] [C4759] closing socket: 0
[2019-07-09 09:07:24.907][29][debug][client] [external/envoy/source/common/http/codec_client.cc:82] [C4759] disconnect. resetting 0 pending requests
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:129] [C4759] client disconnected, failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:164] [C4759] purge pending, failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2019-07-09 09:07:24.907][29][debug][router] [external/envoy/source/common/router/router.cc:671] [C4753][S3527573287149425977] upstream reset: reset reason connection failure
[2019-07-09 09:07:24.907][29][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1137] [C4753][S3527573287149425977] Sending local reply with details upstream_reset_before_response_started{connection failure,TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER}

Reading though this blog I thought I might need to add 

  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key

to the ingressgateway configuration. However, this did not solve the problem. Additionally, since I am using SDS, there won’t be any certificates in ingressgateway-certs (see https://istio.io/docs/tasks/security/auth-sds/#verifying-no-secret-volume-mounted-file-is-generated) as it is described in https://istio.io/docs/tasks/traffic-management/ingress/secure-ingress-mount/

Can anyone point me to a correct configuration? Most of what I find online is referring to the «old» filemount approach…

Источник
  • TLS
    • Underlying implementation
    • FIPS 140-2
    • Enabling certificate verification
      • Example configuration
    • Certificate selection
    • Secret discovery service (SDS)
    • Authentication filter
    • Trouble shooting

    TLS

    Envoy supports both TLS termination in listeners as well as TLS origination when making connections to upstream clusters. Support is sufficient for Envoy to perform standard edge proxy duties for modern web services as well as to initiate connections with external services that have advanced TLS requirements (TLS1.2, SNI, etc.). Envoy supports the following TLS features:

    • Configurable ciphers: Each TLS listener and client can specify the ciphers that it supports.
    • Client certificates: Upstream/client connections can present a client certificate in addition to server certificate verification.
    • Certificate verification and pinning: Certificate verification options include basic chain verification, subject name verification, and hash pinning.
    • Certificate revocation: Envoy can check peer certificates against a certificate revocation list (CRL) if one is provided.
    • ALPN: TLS listeners support ALPN. The HTTP connection manager uses this information (in addition to protocol inference) to determine whether a client is speaking HTTP/1.1 or HTTP/2.
    • SNI: SNI is supported for both server (listener) and client (upstream) connections.
    • Session resumption: Server connections support resuming previous sessions via TLS session tickets (see RFC 5077). Resumption can be performed across hot restarts and between parallel Envoy instances (typically useful in a front proxy configuration).

    Underlying implementation

    Currently Envoy is written to use BoringSSL as the TLS provider.

    FIPS 140-2

    BoringSSL can be built in a FIPS-compliant mode, following the build instructions from the Security Policy for BoringCrypto module, using --define boringssl=fips Bazel option. Currently, this option is only available on Linux-x86_64.

    The correctness of the FIPS build can be verified by checking the presence of BoringSSL-FIPS in the --version output.

    It’s important to note that while using FIPS-compliant module is necessary for FIPS compliance, it’s not sufficient by itself, and depending on the context, additional steps might be necessary. The extra requirements may include using only approved algorithms and/or using only private keys generated by a module operating in FIPS-approved mode. For more information, please refer to the Security Policy for BoringCrypto module and/or an accredited CMVP laboratory.

    Please note that the FIPS-compliant build is based on an older version of BoringSSL than the non-FIPS build, and it predates the final version of TLS 1.3.

    Enabling certificate verification

    Certificate verification of both upstream and downstream connections is not enabled unless the validation context specifies one or more trusted authority certificates.

    Example configuration

    1. static_resources:
    2.   listeners:
    3.   - name: listener_0
    4.     address: { socket_address: { address: 127.0.0.1, port_value: 10000 } }
    5.     filter_chains:
    6.     - filters:
    7.       - name: envoy.http_connection_manager
    8.         # ...
    9.       tls_context:
    10.         common_tls_context:
    11.           validation_context:
    12.             trusted_ca:
    13.               filename: /usr/local/my-client-ca.crt
    14.   clusters:
    15.   - name: some_service
    16.     connect_timeout: 0.25s
    17.     type: STATIC
    18.     lb_policy: ROUND_ROBIN
    19.     load_assignment:
    20.       cluster_name: some_service
    21.       endpoints:
    22.       - lb_endpoints:
    23.         - endpoint:
    24.             address:
    25.               socket_address:
    26.                 address: 127.0.0.2
    27.                 port_value: 1234
    28.     tls_context:
    29.       common_tls_context:
    30.         tls_certificates:
    31.           certificate_chain: { "filename": "/cert.crt" }
    32.           private_key: { "filename": "/cert.key" }
    33.         validation_context:
    34.           trusted_ca:
    35.             filename: /etc/ssl/certs/ca-certificates.crt

    /etc/ssl/certs/ca-certificates.crt is the default path for the system CA bundle on Debian systems. This makes Envoy verify the server identity of 127.0.0.2:1234 in the same way as e.g. cURL does on standard Debian installations. Common paths for system CA bundles on Linux and BSD are

    • /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Gentoo etc.)
    • /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (CentOS/RHEL 7)
    • /etc/pki/tls/certs/ca-bundle.crt (Fedora/RHEL 6)
    • /etc/ssl/ca-bundle.pem (OpenSUSE)
    • /usr/local/etc/ssl/cert.pem (FreeBSD)
    • /etc/ssl/cert.pem (OpenBSD)

    See the reference for UpstreamTlsContexts and DownstreamTlsContexts for other TLS options.

    Certificate selection

    DownstreamTlsContexts support multiple TLS certificates. These may be a mix of RSA and P-256 ECDSA certificates. The following rules apply:

    • Only one certificate of a particular type (RSA or ECDSA) may be specified.
    • Non-P-256 server ECDSA certificates are rejected.
    • If the client supports P-256 ECDSA, a P-256 ECDSA certificate will be selected if present in the DownstreamTlsContext.
    • If the client only supports RSA certificates, a RSA certificate will be selected if present in the DownstreamTlsContext.
    • Otherwise, the first certificate listed is used. This will result in a failed handshake if the client only supports RSA certificates and the server only has ECDSA certificates.
    • Static and SDS certificates may not be mixed in a given DownstreamTlsContext.

    Only a single TLS certificate is supported today for UpstreamTlsContexts.

    Secret discovery service (SDS)

    TLS certificates can be specified in the static resource or can be fetched remotely. Please see SDS for details.

    Authentication filter

    Envoy provides a network filter that performs TLS client authentication via principals fetched from a REST VPN service. This filter matches the presented client certificate hash against the principal list to determine whether the connection should be allowed or not. Optional IP white listing can also be configured. This functionality can be used to build edge proxy VPN support for web infrastructure.

    Client TLS authentication filter configuration reference.

    Trouble shooting

    When Envoy originates TLS when making connections to upstream clusters, any errors will be logged into UPSTREAM_TRANSPORT_FAILURE_REASON field or AccessLogCommon.upstream_transport_failure_reason field. Common errors are:

    • Secret is not supplied by SDS: Envoy is still waiting SDS to deliver key/cert or root CA.
    • SSLV3_ALERT_CERTIFICATE_EXPIRED: Peer certificate is expired and not allowed in config.
    • SSLV3_ALERT_CERTIFICATE_UNKNOWN: Peer certificate is not in config specified SPKI.
    • SSLV3_ALERT_HANDSHAKE_FAILURE: Handshake failed, usually due to upstream requires client certificate but not presented.
    • TLSV1_ALERT_PROTOCOL_VERSION: TLS protocol version mismatch.
    • TLSV1_ALERT_UNKNOWN_CA: Peer certificate CA is not in trusted CA.

    More detailed list of error that can be raised by BoringSSL can be found here

    Источник

    Понравилась статья? Поделить с друзьями:

    Читайте также:

  • Tls error cannot locate hmac in incoming packet from af inet
  • Tls error bio read tls read plaintext error
  • Tls error on connection recv the tls connection was non properly terminated
  • Tls crypt unwrap error packet authentication failed
  • Tls error on connection from

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии