By using AWS re:Post, you agree to the Terms of Use
/AWS App Mesh/

Questions tagged with AWS App Mesh

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

AppMesh mTLS - Unable to verify SSL encryption is established using SPIRE

I'm in the process of setting up a prototype mesh with mTLS. I've gotten to the point where I have my services coupled with envoy sidecars and the sidecars are receiving certificates from SPIRE. I've been following along with this [article ](https://aws.amazon.com/blogs/containers/using-mtls-with-spiffe-spire-in-app-mesh-on-eks/) and am now running into an issue. In their steps, they perform a curl command from a container outside of the mesh and get some TLS negotiation messages. When I try to do the same thing, I get the following: ``` bash-4.2# curl -v -k https://grpc-client-service.grpc.svc.cluster.local:80/ * Trying 10.100.152.100:80... * Connected to grpc-client-service.grpc.svc.cluster.local (10.100.152.100) port 80 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt * CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol * Closing connection 0 curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol ``` Any advice on where I should start to troubleshoot this issue? Here's a rough overview of my setup: There are two pods that represent a client and a server service. The client has a web interface that allows the user to input text. The client takes the input text and submits that to the server service. The server service responds with an echo message that has some extra formatting so you know it came from the server. I've got both pods wrapped in virtual services that connect directly to virtual nodes. I was able to successfully test this with a basic mesh setup prior to adding the SPIRE workload parameters to the services. Within the envoy sidecars, I can see that the SPIRE server is indeed issuing certificates.
1
answers
0
votes
4
views
asked 2 months ago

App Mesh Virtual Service name must be DNS resolvable

The current documentation has a recommendation about the service name: >For Virtual service name, choose a name for your virtual service. We recommend that you use the service discovery name of the real service that you're targeting (such as my-service.default.svc.cluster.local) It does not clearly state that the service name should be a resolvable URL. We have a ECS/Fargate deployment scenario where: - Virtual Service name is `colorteller.default.svc.cluster.local` - it is backed by two Virtual Nodes: - Virtual Node with service discovery options as `colorteller-red.default.svc.cluster.local` - Virtual Node with service discovery options as `colorteller-blue.default.svc.cluster.local` The app container fails even before request is forwarded to envoy because it can't resolve the service by its name (as only red and blue URLs are resolvable via Route53 private DNS). This starts working if a DNS **A record** is created in Route 53 with `colorteller.default.svc.cluster.local` as the key and any random IP as the value. Now the app container can resolve the service name, forward it to envoy and then envoy again does the actual lookup against the Virtual Node's service discovery name and start routing traffic properly. Assuming the above scenario is expected behavior and the Virtual Service name should match at least one Virtual Node discovery name, what are the recommended patterns for doing blue/green traffic transitions? Because in this scenario the deployment would look like: - Virtual Service name is `colorteller.default.svc.cluster.local` - it is backed by two Virtual Nodes: - Virtual Node `red` with service discovery options as `colorteller.default.svc.cluster.local` (please note there is no Red here) - Virtual Node `blue` with service discovery options as `colorteller-blue.default.svc.cluster.local` Now after we deploy the **blue** Virtual Node and start routing all traffic to it based on the weight, we can't bring down our Fargate service running **red** tasks as it will de-register the IP from Route 53 and the DNS lookup against service name will start failing. (Cross-posted from [aws/aws-app-mesh-roadmap#71](https://github.com/aws/aws-app-mesh-roadmap/issues/71))
2
answers
0
votes
7
views
asked 3 years ago
  • 1
  • 90 / page