As the latest ‘hot topic’ in business software, containers are proving increasingly popular among developer teams.
Offering a more portable and lightweight architecture than traditional virtual machines, containers allow an operating system to be abstracted and all software layers above it virtualised. The result is an environment that is very fast to modify to match changes in requirements.
Containers make it easier for IT teams to deploy and manage infrastructures across multiple cloud environments. They also form part of runtime systems that offer a public repository of pre-made containers that can significantly reduce development timelines.
Orchestration and Istio
The increasing use of containers has led to the need for an orchestration platform to aid management. Of these platforms, Kubernetes has become somewhat of a de facto standard across the industry. Indeed, according to research by the Cloud Native Computing Foundation, 83% of its members are already using it in production.
However, while Kubernetes delivers some significant technical and business benefits, as it has grown in maturity, there has emerged an increasing need for better governance and control. This, in turn, has led to the rise of Istio.
Istio is a service mesh that is rapidly becoming a tool of choice for many IT developer teams. It provides a powerful layer of abstraction that aids in the task of achieving effective governance.
Creating an Istio mesh, however, is not for the faint-hearted. To ensure integrity, traffic between containers must be secure, and this requires a strong system of identity. Without this, using Istio could actually introduce concerning new risks.
Achieving effective identity
As a system of authentication, machine identities require a level of oversight to be truly effective, however, Istio only supports self-signed machine identities out of the box. While these IDs might save developers some time and money, they can expose an organisation to additional security risks.
Self-signed IDs are not signed by a publicly trusted Certificate Authority (CA), cannot be revoked, and never expire. If the private key is compromised, having no ability to revoke could open the door to cybercriminals.
In an attempt to mitigate some of this risk, some organisations have begun to issue their own certificates. However, given the number required and the fact that machine identity lifecycles in these environments can be as short as just an hour, this can be become very difficult to manage.
A better approach is to make use of machine ID management tools that deliver full X.509 certificate (i.e., TLS) lifecycle management within Kubernetes. It’s important to select a tool that offers integrated support with a range of machine ID issuers such as ACME and HashiCorp Vault and enables the organisation to work with its preferred PKI solutions.
To achieve this, it will be necessary to replace the existing Istio registration authority with a new service. This service would then perform RA, feature fine-grained policy controls, and integrate with the organisation’s preferred issuer.
Taking this approach will help to automate the process of ID issuance and lifecycle management. This will free up developer time and provide the security and visibility security teams are seeking.
The approach also helps an organisation to be cloud agonistic and make even greater use of multi-cloud infrastructures. This, in turn, will allow developers to take a centralised and fully automated approach to machine ID management throughout their environment.
An Istio-powered future
Service mesh offerings such as Istio offer a dedicated and powerful infrastructure that can automate and simplify processes across the areas of security, observability, and traffic management. However, achieving this requires effective ID management across the entire IT infrastructure.
By seeking out the most appropriate tools and putting them to work together with Istio, IT teams can have the environment they desire while also meeting ID management and compliance demands.