I am new to the whole container-orchestration world and was wondering if the microservices I deploy with Kubernetes need a secure connection too or if the Ingress TLS termination is enough.
For example I have an NGINX microservice with currently no SSL/TLS setup whatsoever. When users communicate with this microservice, the connection is encrypted because I set up an Ingress with TLS termination.
Are there any security drawbacks in such a scenario? I find it very hard to find proper literature regarding this topic.
It definitely will work. I mean ingress with TLS termination. It depends on security requirements of your project. If you ok with un-encripted traffic inside your cluster, you can go with it.
Though, if you will be running micro-services in production, the best practice for secure service-to-service communication is Istio mesh with mutual TLS authentication
What it does is injects sidecar proxy (envoy) for each of your services
Related
I am trying to convert an Istio service mesh running on k8s from http to https but stumbled upon many problems. I don't really understand what are all the steps required to do that.
As I know, there are 2 kinds of traffic that requires TLS in a mesh:
between internal services: scramming through Istio docs let me know that Istio will somehow automatically configure mTLS between services so all of them will communicate securely without any extra configuration. However, I still don't understand deeply how they implement this mTLS. How does it differ from normal TLS and what is mTLS role in the other kind of traffic (client outside to service inside)?
from client outside to a service inside: this is where I don't know what to do. I know that in order for a service to have TLS it needs TLS certificate by a trusted CA. However, as the outer client will not talk directly to the service inside but only through the Istio ingress gateway. Do I need to provide cert for every service or only the ingress gateway? All of my services are now exposing port 80 for HTTP. Do I need to convert all of them to port 443 and HTTPS or just the ingress gateway is enough?
Regarding the certificates, if I just use self-signing certs for now, can I just create cert and key with openssl and create secrets from it (maybe sync between namespaces with kubed), then all services use the same cert and key? Everywhere suggests me to use cert-manager. However, I don't know if it is worth the effort?
I would be really thankful if anyone can explain with some illustrations.
In general, if you need a good explanation of the issues related to Istio (also with pictures), I recommend that you check the documentation. You can find around 540 topics related to TLS in Istio.
Istio is a very well documented service. Here you can find more information about Understanding TLS Configuration. You can also find good article about Mutual TLS Migration.
However I still don't understand deeply how they implement this mTLS, how does it differ from normal TLS and what is mTLS role in the other kind of traffic (client outside to service inside).
Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification. You can read more about it here. Additionally yo can also see page about HTTP Traffic (mTLS is required for this case).
All of my services are now exposing port 80 for HTTP. Do I need to convert all of them to port 443 and HTTPS or just the ingress gateway is enough?
It is possible to create Ingress Gateway without TLS Termination:
The Securing Gateways with HTTPS task describes how to configure HTTPS ingress access to an HTTP service. This example describes how to configure HTTPS ingress access to an HTTPS service, i.e., configure an ingress gateway to perform SNI passthrough, instead of TLS termination on incoming requests.
EDIT (added more explanation and documentation links):
Service mesh uses a proxy to intercept all your network traffic, allowing a broad set of application-aware features based on configuration you set.
Istio securely provisions strong identities to every workload with X.509 certificates. Istio agents, running alongside each Envoy proxy, work together with istiod to automate key and certificate rotation at scale. The following diagram shows the identity provisioning flow.
Peer authentication: used for service-to-service authentication to verify the client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication, which can be enabled without requiring service code changes.
Peer authentication modes that are supported: Permissive, Strict, and Disable.
In order to answer this question:
All of my services are now exposing port 80 for HTTP. Do I need to convert all of them to port 443 and HTTPS or just the ingress gateway is enough?
fully we could have informed the customer that using Istio Gateway can expose services from Istio service mesh to the outside using plain HTTP, with TLS termination or in PASSTHROUGH TLS mode. Incoming TLS termination could be improved (using TLS certificate approved by a trusted CA or using cert-manger with Istio Gateway). You can read more about this topic here.
I have a scenario where an external app (not on Istio) is calling our services to get some data. Client sends in it's certificate in the WebRequestHandler that we validate as a way to authenticate the client. Can this be done at the ingress-gateway level?
Please note that I am also terminating the TLS traffic at the gateway and forwarding the request to the corresponding services on different pods based on http url-regex matching. I am also okay to validate the certificate in my service's code given it reaches the service as it is (excuse me for sounding naive here, I am very new to this).
Thank you!
If you want mutual TLS between an external service and Istio's Ingress Gateway then that's possible and is documented here: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/
I try to understand why Istio have the mTLS feature? It enables mutual TLS authentication between all the services in a cluster via automatically issued certificates.
Mandatory TLS authentication is a benefit only as long as they are services outside Istio, but when Istio is enabled globally in Kubernetes, this is not the case - then every service gets certificate automatically, so can connect to any other.
Maybe TLS is used as identity provider, required by Istio authorization rules, like asked in yet unanswered Does istio authorization have effect if mtls is not used for istio authentication?? But why Istio does not just use Kubernetes service accounts as identity provider. This is even mentioned in documentation.
Also, even with TLS for identity, why encrypting traffic (TLS can be used without encryption)? I am assuming here that the container is not able to spoof IP address.
I have client server application which using WCF service with Transport security mode and NetTCP binding. I heard like Transport security is best for local intranet, not for internet. Now my scenario is I need to access WCF service over internet (from another country), but dont want to use Message security (cause it need to purchase and install certificate on server and each client). I want to use Transport security and also encrypt my data, so no one can hack it from internet.
So please someone guide me how can I encrypt my data with Transport security ?
Thanks
Transport is just SSL, so after the initial setup on the host and client sides, there's really nothing special to it. SSL will encrypt all the bytes starting at byte 0 and only the host that distributed the public key portion of the SSL cert will be able to decrypt the transmission since it and only it should have the private key part of the certificate.
SSL does present some potential problems if you have a load balancer or proxy fronting your service - i.e. if the proxy or LB server didn't begin the SSL transmission, it won't know what to do with the inbound message. But SSL encryption can be offloaded to a LB or proxy, so there are ways around that.
Here's a link to a stackoverflow question about SSL over WCF
Enable SSL for my WCF service
We are in the process of moving a 2-way SSL enabled web service to Amazon Web Service cloud. Since AWS doesn't support 2-way SSL, I was thinking if it is possible to decouple the 2-way SSL process: Terminate the SSL at the Elastic load balancer but validate the client cert in the CXF application using custom code?
I don't prefer to make our clients to change their implementations from the current 2-way SSL setup.
You could do this using TCP load balancing and terminating the SSL connection at your server instead. Somewhat more info here under "Using Back-End Server Authentication with Elastic Load Balancing":
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html