hscheib
commented
3 years ago This is a similar problem to the request above.
We have our mesh set to DROP_ALL by default and have added any EKS app backends and database backends to the appropriate apps and all traffic works as expected. We have an external non AWS https request that fails even when we have it added as a virtual service and virtual node and set as a backend.
My use case is for https://redacted.auth0.com domain and when we try to curl that service the request fails for a TLS error
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
We are getting around this by adding appmesh.k8s.aws/egressIgnoredPorts: "443” to our EKS pods. This now opens up every service on 443 on the internet to that app which is not in line with DROP_ALL paradigm and allowing only defined backends.
This closed issue seems to be related. We want to keep apps as locked down as possible, and this seems to be the last link in our least permissible chain.
If you want to see App Mesh implement this idea, please upvote with a :+1:.
Tell us about your request Today App Mesh allows endpoints within the mesh to communicate with all AWS services (
*.amazonaws.com) without the customer needing to explicitly define them as backends. However, some AWS services have different domains, such as Amazon Cognito (*.amazoncognito.com). It would be great to automatically allow egress traffic from endpoints within the mesh to Cognito.Which integration(s) is this request for? All
Are you currently working around this issue? It's possible to model Amazon Cognito as a Virtual Service and a Virtual Node where the Virtual Service name and Virtual Node DNS hostname is the same as the exact Cognito domain used. However, for this to work, the proxy will need to initiate TLS using a client policy, and the application will need to disable TLS for Cognito communication (see #162 for why this is the case).