Details
-
Ticket
-
Resolution: Done
-
Normal
-
None
-
OSSM 2.3.0
-
None
-
False
-
None
-
False
-
Sprint 62
Description
In a ServiceMesh installation that block all outgoing traffic, the proxies can by bypassed by creating a headless service instead of a ServiceEntry.
Need clarification to know if behaviour is expected.
How to reproduce the issue.
- Deploy a webserver outside of the mesh.
- Deploy a pod in a namespace that is part of the mesh.
When you try to connect to the webserver from the first point, the connections will be rejected:
# oc exec -ti sleep-cc6868676-fwnlw -- curl -v 192.168.122.5:8080/status/418 * About to connect() to 192.168.122.5 port 8080 (#0) * Trying 192.168.122.5... * Connected to 192.168.122.5 (192.168.122.5) port 8080 (#0) > GET /status/418 HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 192.168.122.5:8080 > Accept: */* > * Recv failure: Connection reset by peer * Closing connection 0 curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56
And the istio-proxy log will show the traffic being rejected:
[2023-01-19T09:36:28.629Z] "- - -" 0 UH - - "-" 0 0 0 - "-" "-" "-" "-" "-" BlackHoleCluster - 192.168.122.5:8080 10.128.2.27:34086 - -
- Create a Service and an Endpoint for the IP address of the webserver in point 1:
apiVersion: v1 kind: Service metadata: name: extsvc-httpbin spec: clusterIP: None ports: - name: http port: 8000 protocol: TCP targetPort: 8000 --- apiVersion: v1 kind: Endpoints metadata: name: extsvc-httpbin subsets: - addresses: - ip: 192.168.122.5 ports: - name: http port: 8000 protocol: TCP
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/extsvc-httpbin ClusterIP None <none> 8000/TCP 7sNAME ENDPOINTS AGE endpoints/extsvc-httpbin 192.168.122.5:8000 7s
- When you connect to the headless service name, the connection is allowed:
oc exec -ti sleep-cc6868676-fwnlw -- curl -v extsvc-httpbin:8000/status/418 * About to connect() to extsvc-httpbin port 8000 (#0) * Trying 192.168.122.5... * Connected to extsvc-httpbin (192.168.122.5) port 8000 (#0) > GET /status/418 HTTP/1.1 > User-Agent: curl/7.29.0 > Host: extsvc-httpbin:8000 > Accept: */* > < HTTP/1.1 418 Unknown < server: envoy < date: Thu, 19 Jan 2023 09:39:35 GMT < x-more-info: http://tools.ietf.org/html/rfc2324 < access-control-allow-origin: * < access-control-allow-credentials: true < content-length: 135 < x-envoy-upstream-service-time: 3 < -=[ teapot ]=- _...._ .' _ _ `. | ."` ^ `". _, \_;`"---"`|// | ;/ \_ _/ `"""` * Connection #0 to host extsvc-httpbin left intact
And the istio-proxy logs show the connection going through:
[2023-01-19T09:39:35.760Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 4 3 "-" "curl/7.29.0" "cb9fa100-529c-9ee4-9fba-032bd16ffa3d" "extsvc-httpbin:8000" "192.168.122.5:8000" outbound|8000||extsvc-httpbin.mesh-bypass.svc.cluster.local 10.128.2.27:48594 192.168.122.5:8000 10.128.2.27:48578 - default
Why is this connection being allowed if no ServiceEntry has been defined?
Creating the headless Service and the Endpoint generate a Cluster and a Route in envoy, but not a Listener. Whereas creating a ServiceEntry generates a Listener, a Cluster, and a Route.