Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Testing Microservices with Mountebank: individual microservice testing using virtualization

2,024 views

Published on

Testing Microservices with Mountebank is your guide to the ins and outs of testing microservices with service virtualization. Mountebank solves the microservice testing conundrum through service virtualization - imitating other components in the system so that you can test a microservice in isolation.

Save 42% off Testing Microservices with Mountebank with code slbyars at: https://www.manning.com/books/testing-microservices-with-mountebank

Published in: Software
  • Be the first to comment

Testing Microservices with Mountebank: individual microservice testing using virtualization

  1. 1. Setting up an HTTPS Imposter by Brandon Byars Save 42% off Testing Microservices with Mountebank with code slbyars at manning.com.
  2. 2. Services require security. An important step in testing microservices is layering in security. Let’s use the example of HTTP. Adding security to HTTP means using HTTPS.The "S" stands for SSL/TLS, which adds encryption, and, optionally, identity verification to each request. On the next slide there is a diagram of the basics of SSL.
  3. 3. The SSL layer of HTTPS is handled by the infrastructure so that, as far as the application is concerned, each request and response is just standard HTTP.The way the security works is a bit more complex though…
  4. 4. The key concepts that make HTTPS security work are the server’s certificate and the server’s keys. The certificate basically validates the server’s identity and credentials to the client during the “handshake” process. Certificates are one of the foundations of trust on the Internet. The certificate also includes the server’s public key, used to encrypt a message. But, instead of using the same key to decrypt, SSL uses a neat trick to enhance security – there is a separate private key, used for decryption, that is only in the possession of the server. Pretty cool!
  5. 5. So even if someone snags your message during transmission and has the public key, they can’t decrypt it because they don’t have the private key!
  6. 6. Now we’re ready to set up our HTTPS imposter and get down to testing! If you know how to set up a HTTP imposter, they you’re already 99% off the way to its HTTPS cousin – simply set the protocol to HTTPS instead of HTTP. This is great for quickly setting up an HTTPS server, but it uses a default certificate (and key pair) that ships with mountebank. This is ok for some kinds of testing, but you really ought test using a trusted certificate from a Certificate Authority (CA)
  7. 7. --Word to the wise-- Don’t configure the service you’re testing not to validate that the certificate is trusted. The chance that code like this might be left in at production is a risk that you don’t want to take. The whole point of testing, after all, is to gain confidence in what you’re sending to production, which requires that you actually test what’s going to production. So use a trusted certificate in the test environment! Let’s see how you can set up your test instances of your virtual services with appropriately trusted certificates.
  8. 8. Let’s set up ourTest environment.With this approach, the test creates the imposter with both the certificate and the private key.You can also pass them in what is known as PEM format.
  9. 9. The listing below shows our HTTPS imposter.This setup is still insecure in that the test needs to know the private key to create the imposter, so the imposter knows how to decrypt communication from the system under test. The actual text is much longer than what is shown here. *The certificate is tied to the domain name in the URL, so as long as you segment that domain name to your test environment, you’re not risking leaking any production secrets.
  10. 10. With appropriate environment separation, the approach (from the previous slide) allows you to test the system under test without changing its behavior to allow untrusted certificates. Let’s move on to setting up our HTTPS imposter. Obtaining a certificate from a CA has historically been a real pain, but these days it has become much easier. Let’s Encrypt (letsencrypt.org/) is a free option that supports creating certificates for domains with minimal fuss, backed by a public CA. Neato!
  11. 11. Let’s Encrypt uses a command line tool called "certbot" (certbot.eff.org/#ubuntutyakkety-nginx) to automate the creation of certificates. Below is a diagram showing how Let’s Encrypt works its magic.
  12. 12. The actual certbot command depends on the web server you’re using, and since it is constantly evolving, you should check their documentation for the details. In a general case, you might run: That would create a certificate for the test.petstore.com domain that’s served out of a web server running in /var/test/petstore.
  13. 13. By default, that directory certbot stores the SSL information in is /etc/letsencrypt/live/$domain, where $domain is the domain name of your service. If you look in that directory, you’ll find a few files, but two relevant for our purposes: privkey.pem contains the private key, and cert.pem contains the certificate. The contents of those two files are what you would put in the key and cert fields when creating the HTTPS imposter. A PEM file has newlines. An example certificate might look like the image on the next slide.
  14. 14. An example certificate might look like the following:
  15. 15. You’ll want to keep the newlines, escaped in typical JSON fashion with 'n', in the strings you send mountebank. In this example, shortening the field for clarity, the resulting imposter configuration might look like this: Note that, while it seems awkward here, the string would include all the way up to the end of the file (e.g., "…nWWrz80cauVHn-----END CERTIFICATE-----" for the certificate). And… that’s it. Everything else about our imposter remains the same.
  16. 16. Once we’ve set the certificate and private key, the SSL layer is able to convert encrypted messages into HTTP requests and responses, which means the is responses we’ve already created continue to work. It may seem like a fair chunk of work to actually set up the certificates, but that’s the nature of SSL. Fortunately, tools like Let’s Encrypt and shortcuts like using wildcard certificates simplify the process considerably. Now, let’s move on to using mutual authentication.
  17. 17. --Certificates aren’t just for servers anymore— It turns out that certificates aren’t only valid for HTTPS servers; they’re also a common way to validate the identity of clients. You don’t see this when browsing the internet because public websites can’t afford to make assumptions about the browsers that access them, but in a microservices architecture, it’s important to validate that only authenticated clients can make a request to a server. Let’s see how an environment to test this can be set up.
  18. 18. If the service you’re testing expects to validate its identity with your imposter using a client certificate, then your imposter needs to be able to be configured in a way that expects that certificate.
  19. 19. Configuring your imposter is as simple as adding a mutualAuth field to the configuration: When true, the server expects a client certificate. * Now the server will challenge the client with a certificate request. Using certificates, both for HTTPS and for mutual authentication, allows you to virtualize servers in secure environments.Try to keep in mind that the fact that we have to escape the PEM files in JSON gets quite clunky.
  20. 20. That’s all for now! Hopefully, you’ve gained an interest in using Mountebank to test microservices. Don’t forget to save 42% off Testing Microservices with Mountebank with code slbyars at manning.com. Also see:

×