The Istio service mesh project is an up-and-coming open-source effort that already has the backing of major IT vendors that include IBM, Cisco, Google and Amazon. Istio however isn’t secure by default, which is something that Twistlock is trying to help organizations configure, with a new guide to compliance checks released on Feb. 11.
The Isto service mesh enables a more efficient type of container to container, or microservice to service communications and networking model, by offloading the connectivity to a side car proxy. With Istio, more complex distributed microservice architectures can be built and deployed, but there are multiple key steps that organization should take before putting Istio into production.
“There’s a hesitancy to turn things on by default, because you’re not sure what will break,” John Morello, CTO of Twistlock told eWEEK. “So, you know, being a security person by trade, I always would prefer people build things in more of a secure by default manner, but it’s not really what we’ve seen in this ecosystem.”
Istio hit its 1.0 milestone on July 31 and is closely associated with the open-source Kubernetes container orchestration project. Much like Istio, Kubernetes has been developed over a period of time, with necessary security controls not always on by default. Twistlock is in the business of helping organizations to secure cloud-native container and Kubernetes environments and has been looking at ways to help organizations keep Istio secured.
TLS Authentication With Mesh Policy
There are multiple core elements that make up an Istio deployment, among them is the Mesh Policy, which helps to define the core configuration for a service mesh deployment. Morello explained that lstio has the integrated concept of being able to do configure things at the mesh level, which is environment wide. Istio also has ability to configure things at a component level based on each individual service that’s part of that mesh.
One of the recommendations that Twistlock has for Istio is to configure TLS (Transport Layer Security) with Mesh Policy. With TLS, communications between different nodes in the service mesh is encrypted in transit.
“When we’re talking about turning it on TLS at the mesh policy level, we’re doing that because if you turn it on there, then everything else inherits that setting by default,” Morello said.
The TLS implementation that is already part of Istio, is in a feature known as Citadel, the challenge is that TLS is not on by default and administrators need to turn it on. Morello explained that with Citadel, Istio gets a full mutually authenticated TLS model, without the need for users to get their own TLS certificates from a Certificate Authority.
“Istio itself is able to manage certificates and you don’t ever have to really worry about it, you just set Istio to use TLS and it handles the certificates and the configurations required to do so,” he said.
Set RBAC Config Mode To On
Role Based Access Control (RBAC) is a critical security feature than enables administrators to set access policy based on the role of the service or the user. Much like TLS, RBAC capabilities are part of Istio, but there are not set to be active by default. Istio is currently being built and deployed alongside the Kubernetes container orchestration system which has its own RBAC implementation as well, though Istio doesn’t inherit any RBAC setting from Kubernetes.
Turning RBAC on for Istio is a bit more complicated than simply flipping a switch, as there is also a need to understand and define how the RBAC should be configured. Morello suggests that administrators start off by creating a default policy to help determine the correct settings. One option is to have RBAC turned on everywhere, which Morello doesn’t think is likely the best choice for many deployments as it would break some service availability. Rather, Morello suggests that more organizations start with either an inclusion or exclusion RBAC policy.
“What we recommend is to turn RBAC on with exclusion because it provides you the ability to say the default is that everything is going to use RBAC, but if you have a situation where something cannot use RBAC, then you can just manually opt out that specific app,” he said.
Currently Twistlock’s best practises for Istio security configuration is available in a guide that is freely available. Morello said that Twistlock will likely also make a tool available in the coming months, that will help Istio users validate configuration.
“This is a paper that we’re putting out as kind of an open-source announcement on how to secure Istio and an invitation for others to participate in creating further standards around Istio compliance and security configuration,” he said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.
