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.
Related
I'm building a service that require PKI MTLS X509Certificate authentication.
So I have an AWS ACM Private CA that issues private client certificates to identify the client and regular ACM issued certificate to identify the server.
For the MTLS authentication I use Spring security (Java), which requires a trust store containing the private root CA certificate for authenticating clients as well as a PKCS#12 key store to enforce SSL (for the client to authenticate the server).
Everything works fine when I run it locally using SSL.
Before I enabled SSL in the application, everything worked fine in the cluster as well.
However, when I added MTLS logic to the application the connection hangs when talking to the application in the cluster.
I'm guessing that I need to configure https for my service/ingress in the cluster, but everything I find specifies an arn for the certificate to be used, while I already have it installed in the application.
All I want to do is to allow https traffic to pass through the load balancer into my application and let the application handle the SSL stuff.
Alternatively if it would be possible to configure X509Certificate authentication in Spring security without the SSL certificate for the client to verify the server.
In that case the SSL certificate would only be used in production and not locally.
Would that be possible and what's the pros and cons with each?
So in the end I ended up using the nginx ingress controller with ssl-passthrough.
However, EKS Fargate pods do not support the nginx ingress controller, so I had to create a new managed cluster.
Technically I could have used mixed cluster with both managed and Fargate nodes, but I felt that Fargate had given me enough headache and when I did some calculations I found that Fargate probably costs more in our case.
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 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
I'm studying for this exam identity & access management. The question is what is the difference between one way authentication and mutual authentication? Our prof says mutual is TLS but if I search on the internet TLS is also one way authentication... So I'm a bit confused
I have implemented both one-way and mutual SSL in Applications hosted on Java and Webmethods technology. In One-way authentication, there is a server certificate that the client receives, trusts it (registers it) and sends back a secret along with the server certificate. Hence, a successful SSL Handshake occurs.
In mutual SSL, in addition to trusting the Server Certificate, the Client also provides it's own certificate to the Server. Hence, a mutual trust is maintained between the Server and the Client after which the secrets are transferred.
TLS is a protocol for guaranteeing security in the exchange of information. It is used in particular on the HTTP protocol. The TLS protocol allows both unilateral authentication and bilateral authentication (or mutual authentication). Recently I published on GitHub a project that implements a system of Mutual Authentication based on Apache 2.4 and the TLS 1.2 protocol. https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/
The attached image shows the call to a REST service in mutual authentication
I have two WCF Services using WsHttpBinding with transport security mutual certificate authentication that are being hosted on the same windows server. Clients that can access one WCF service should not have access to the other WCF service. I need some help on configuring the client certificates on the windows host. The client certificates are signed by trusted CAs and the intermediate and root certificate chain is already installed on the the server. It seems like the service automatically relies on chain of trust and does not require the actual client certificates installed on the server at all before letting the client access the service - this is not the behavior I want. Can someone please tell me how I should be configuring these client certificates in order explicitly allow access to one service and not the other?
Thanks.
That has nothing to do with certificates themselves. When using mutual SSL authentication certificates are used only to authenticate client and the authentication is done outside of your application (this is difference to message security where you can create custom certificate validator). Once certificate is trusted client is automatically authenticated to anything on the server using certificates for authentication.
You are looking for authorization - the step where you define what can authenticated client do with your service. You can either hardcode your authorization logic into your service by using role based security or you can implement two custom ServiceAuthorizationManagers and assign each to single service.