3 ms·

I am sort of surprised that the solution to encrypting your traffic isn't using HTTPS internally, and people rolled these wild systems of proxies. It makes sens

I am sort of surprised that the solution to encrypting your traffic isn't using HTTPS internally, and people rolled these wild systems of proxies. It makes sense thinking about it now because you have no idea whether you need the encryption or not (two containers may be on the same host), but this seems to be a pyrrhic victory. Once again, the bad implications of a seemingly good idea come to bite us.

sweetjuly 3y ago
It does have some advantages in that you don't have key material on every single server. How much this risk actually matters will vary. I suspect most enterprises would actually be relatively safe with their frontend certificates being compromised, though the same cannot be said about the actual compromise of the backend application.
- pclmulqdq 3y ago
  I assume you would either use self-signed certs or run a private CA to do this. You wouldn't get the attestation benefits, but there's no material of any value in each container if you do this. The encryption is the only benefit. Reading that comment, I sort of understand why people don't do this because it takes some understanding of HTTPS and cryptography to do this properly.
cyberax 3y ago
It boils down to the complexity of running an internal DNS and of issuing certificates. If you don't do that, HTTPS is useful only for encryption against passive eavesdroppers.
flumpcakes 3y ago
The solution _is_ running HTTPS internally. But as an application developer, do you want to manage certificates? Do you want to make sure you're using the "correct" TLS versions and that your app can talk to other TLS versions? What happens when team Z deploys their legacy Java app that doesn't? Where are you getting your certificates from? All of these go away with a service mesh and sidecar model where the everything is encrypted for you and certificates are completely managed by the service mesh. No need to roll your own PKI. Your app only needs to speak plain HTTP and from it's perspective every other app is also just speaking plain HTTP, no TLS in sight. It makes developers' jobs a lot easier, only concentrating on shipping features vs. wrangling with TLS. Saying all of that, you could just roll your own fine. Depending on the competency of your company.
- DinaCoder99 3y ago
  > But as an application developer, do you want to manage certificates? It might take years of trying to avoid TLS to learn that all the alternatives are far worse. So—yes, just bite the bullet, it's not that bad once you internalize the model, and you really only need to solve this once per organization.
- lomereiter 3y ago
  To set up an open-source service mesh, the infra team anyway has to configure a private certificate authority and cert-manager to create k8s secrets for the service mesh components. From there, it's straightforward to extend the common deployment template (hopefully there is one) to mount a volume with an auto-rotated certificate. All an application developer has to do is to use that certificate, which is much less effort than what you are implying.
  - MrDarcy 3y ago
    It’s not less effort. I’ve done both ways in production for large teams. What you described is literally entirely automated by the mesh in a more secure and maintainable way than a bespoke hand rolled solution.
    - lomereiter 3y ago
      "Large teams" is the key, there has to be enough services and/or language diversity to justify the extra complexity.
- vbezhenar 3y ago
  The first thing developer does implementing HTTPS is chatgpting "how do I disable certificate validation". There's no way I'd trust random developer to implement mTLS properly.
  - remram 3y ago
    You can trust that the same way you trust any other part of your product. Code review, automated test. If adding basic mTLS security to every service is that much of a pain, maybe you have too many of those?
marcosdumay 3y ago
What I get is that the proxies are a really complete "not my problem" solution, that puts all the burden of setting-up the network encryption on the hands of the people with direct access to set-up and debug your network. If this doesn't look like a real thing to you, congratulations, you are in a well run organization that doesn't have this problem. Anyway, whether the costs of this thing are worth the gain, I have no idea.

sweetjuly 3y ago

It does have some advantages in that you don't have key material on every single server. How much this risk actually matters will vary. I suspect most enterprises would actually be relatively safe with their frontend certificates being compromised, though the same cannot be said about the actual compromise of the backend application.

pclmulqdq 3y ago
I assume you would either use self-signed certs or run a private CA to do this. You wouldn't get the attestation benefits, but there's no material of any value in each container if you do this. The encryption is the only benefit. Reading that comment, I sort of understand why people don't do this because it takes some understanding of HTTPS and cryptography to do this properly.

cyberax 3y ago

It boils down to the complexity of running an internal DNS and of issuing certificates. If you don't do that, HTTPS is useful only for encryption against passive eavesdroppers.

flumpcakes 3y ago

The solution _is_ running HTTPS internally. But as an application developer, do you want to manage certificates? Do you want to make sure you're using the "correct" TLS versions and that your app can talk to other TLS versions? What happens when team Z deploys their legacy Java app that doesn't? Where are you getting your certificates from? All of these go away with a service mesh and sidecar model where the everything is encrypted for you and certificates are completely managed by the service mesh. No need to roll your own PKI. Your app only needs to speak plain HTTP and from it's perspective every other app is also just speaking plain HTTP, no TLS in sight. It makes developers' jobs a lot easier, only concentrating on shipping features vs. wrangling with TLS. Saying all of that, you could just roll your own fine. Depending on the competency of your company.

DinaCoder99 3y ago
> But as an application developer, do you want to manage certificates? It might take years of trying to avoid TLS to learn that all the alternatives are far worse. So—yes, just bite the bullet, it's not that bad once you internalize the model, and you really only need to solve this once per organization.
lomereiter 3y ago
To set up an open-source service mesh, the infra team anyway has to configure a private certificate authority and cert-manager to create k8s secrets for the service mesh components. From there, it's straightforward to extend the common deployment template (hopefully there is one) to mount a volume with an auto-rotated certificate. All an application developer has to do is to use that certificate, which is much less effort than what you are implying.
- MrDarcy 3y ago
  It’s not less effort. I’ve done both ways in production for large teams. What you described is literally entirely automated by the mesh in a more secure and maintainable way than a bespoke hand rolled solution.
  - lomereiter 3y ago
    "Large teams" is the key, there has to be enough services and/or language diversity to justify the extra complexity.
vbezhenar 3y ago
The first thing developer does implementing HTTPS is chatgpting "how do I disable certificate validation". There's no way I'd trust random developer to implement mTLS properly.
- remram 3y ago
  You can trust that the same way you trust any other part of your product. Code review, automated test. If adding basic mTLS security to every service is that much of a pain, maybe you have too many of those?

marcosdumay 3y ago

What I get is that the proxies are a really complete "not my problem" solution, that puts all the burden of setting-up the network encryption on the hands of the people with direct access to set-up and debug your network. If this doesn't look like a real thing to you, congratulations, you are in a well run organization that doesn't have this problem. Anyway, whether the costs of this thing are worth the gain, I have no idea.