2

Background We have a number of backend api's that do work; some connect to equipment, some store data, etc. The original setup was each service was a native c# asp.net 6 minimal api running on a windows server 2022. I was able to convince the right people we should be using docker, but as a compromise, I had to write a custom orchestration app to manage each instance and allow for each service to run natively or in a docker container. Kubernetes isn't in the cards. The sell was the devops part with a container registry and simple deployment pipeline, extending that to kubernetes may be too much.

All is good Fast forward, we now have all the apps working and talking to each other and their distribution is configurable. The custom orchestration allows for simple switching between native exe processes and containers, as well as configuring multiple servers to run various instances of these apps. The base image is aspnet:6.0. Deploying updates is a drop down list.

Then came SSL certificates. They are a nightmare so far. I don't have much experience working with them in general, and trying to get two docker containers living on two different servers to use self signed certificates living on the host OSes is troublesome. Mostly passing the certificates to the docker containers (as a client) on creation. Dialing into a docker container from a client side native app works fine, but dialing out from a client side docker container to another docker container doesn't. Unfortunately, the native apps work just fine, so the work in convincing others I had managed is in the toilet for docker if I don't pull something together.

Question Is it best practice to put a reverse proxy server in front of our services regardless of docker and could something like nginx potentially solve my SSL certificate problems?

Note: I'm thinking the custom orchestration app could install and configure a container for an nginx service on startup and I could point all of the containers and native apps at that service for all SSL communication. This would allow us to not worry about encryption and keys on our end but be an implementation detail in production.

Any guidance or thoughts would be appreciated. This is new territory for me.

enter image description here

I added a diagram of what's happening. When I create the containers I'm able to add the cert for the container to use with inbound messages just fine. aspnet:6.0 has environment variables designed to handle that. ASPNETCORE_Kestrel__Certificates__Default__Path and ASPNETCORE_Kestrel__Certificates__Default__Password. But those handle the inbound encryption, not accepting a self signed certificate for an outbound message. I don't think the container is getting the installed self signed certificates from the host for use. I suspect I would need to install the client certs in the container somehow. We tried mounting a volume to a directory containing the .pfx files but we keep getting "object not found" from the encryption library. Which seems like a symptom of it not being in the proper certificate store on the machine.

Improve this question
9
  • 1
    Could you clarify the exact TLS issue, perhaps by showing a diagram? Are you trying to deploy self-signed certificates so that the containers can encrypt their communication among each other? Or are you trying to deploy certificates so that outside clients can connect to the containerized services securely?
    – amon
    Commented Mar 5, 2023 at 6:51
  • you should be able to put the required certs on your images when they are built?
    – Ewan
    Commented Mar 5, 2023 at 13:31
  • @amon thanks for the feedback. I added a diagram to try and clarify. As to your question. I'm trying to do both. They need to communicate among each other, possibly from different hosts, as well as handle incoming requests.
    – Felix Castor
    Commented Mar 5, 2023 at 14:55
  • @Ewan I was able to add the cert for Kestrel to use for incoming requests, it's when the container is trying to reach out that's the problem.
    – Felix Castor
    Commented Mar 5, 2023 at 15:00
  • 2
    im guessing the cert on the target machine uses a root cert thats not on your docker image. you need to install and trust the target cert chain
    – Ewan
    Commented Mar 5, 2023 at 15:41

1 Answer 1

Reset to default
2

I think i would have to say that best practice here is to use an application gateway to do the ssl and not have any ssl on the containtered services themselves.

ie

client -> https -> app gateway -> http -> api

api -> http -> api2

This way the application gateway is the only component to do the ssl termination. everything else is firewalled and unencrypted.

This gets around the problem by having no certificates on the api containers at all and means you only need to manage one point of contact for certs and firewalls

Improve this answer
3
  • If we weren't using docker, would you still recommend a reverse proxy?
    – Felix Castor
    Commented Mar 6, 2023 at 13:26
  • personally, I slap SSL on everything. But I think that's an outdated approach. You should trust the firewall to hide the actual services and have an API gateway to handle all the auth/ssl/instruction pages/swagger/rate limiting etc etc. This approach gells nicely with containers, because you can consider your containers just nodes in a LB and they don't have to deal with any shared knowledge, but its equally valid with a classic infrastructure of DMZ/Private network zones and virtual machines
    – Ewan
    Commented Mar 6, 2023 at 13:58
  • I second this. I have worked with large architectures with hundreds of services and applications of all sorts and, containers or not, there's often only a single point of trust regarding SSL. Everything beyond (behind) that point runs without SSL. Especially if the CA is also self-signed (CAs self-signed are common in private networks) because it implies installing the damn CA in every single trust store.
    – Laiv
    Commented Mar 6, 2023 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.