Enable Microservices Authentication With Sensedia Service Mesh

Microservices stand out as one of the most prominent components in contemporary software architecture. It has garnered widespread attention, with numerous internet articles attempting to clarify its benefits and drawbacks. 

Drawing from personal experience accumulated over several years of working with microservices, the most challenging aspect becomes apparent in the realm of security implementation and API Governance within this architectural framework. Addressing security concerns in microservices poses a notable challenge, and various patterns and tools have emerged in an attempt to resolve this issue.

The majority of these solutions are intricately connected to the specific programming languages and frameworks employed in the microservices landscape. As the demand for robust security measures within microservices continues to grow, navigating the available patterns and tools becomes a crucial aspect of ensuring a secure and agile architecture.

That way, we have a sort of problem because we need to apply security in the “Software” layer, and it might cause issues including

• Incorrect implementation by developers;
  
  
• Different implementation because the frameworks “imply” their patterns like Spring Security or Apache Shiro;
  
  
• Usually, languages imply their patterns as well;
  
  
• Added certificates in the application layer adds some extra complexity to managing these certificates;
  
  
• The framework should support certificate configuration;
  
  
• Security implemented with different patterns in the Solution;
  
  
• Developers don’t know the security standards in-depth, which causes some security leaks.

Security is a non-functional requirement, and in most companies, a specific area will define standards and manage security throughout internal and partner ecosystems. It means defining network firewalls, network privileges, and so on.

The imperative lies in establishing a standardized approach to security within our microservices solution. ISTIO, functioning as a service mesh architecture and aligning with DevOps practices, presents itself as a viable solution to seamlessly incorporate protection measures into the platform, specifically within the context of Kubernetes.

The utilization of ISTIO offers a simplified avenue to comprehend and implement security protocols, providing a robust framework for safeguarding the microservices environment. 

Now, let’s explore ISTIO and learn how it helps make our microservices more secure when we use them with Kubernetes.

‍

Authentication Types in ISTIO

ISTIO provides two distinct types of authentication mechanisms. The first is designed for end-users, focusing on user authentication. The second is tailored for service-to-service communication and involves authentication using certificates. 

In the upcoming discussion, we will dive deeper into both of these authentication models to gain a more comprehensive understanding of their API governance functionalities and implementations within the ISTIO framework.

‍

End-User Authentication

The End-User Authentication feature in ISTIO is dedicated to validating individuals attempting to access our system, whether a human user, a basic device, or an application seeking entry into our solution.

ISTIO leverages the JSON Web Token (JWT) specification, a widely adopted and prevalent security standard for cloud-native applications, to facilitate request-level authentication. Furthermore, ISTIO offers straightforward integration with the OpenID Connect specification, another prominent standard in the realm of security.

For fortifying the security of our microservices, ISTIO allows the implementation of the OAuth authentication flow through a concise set of configurations. These configurations include essential parameters like JWT Issuer, JWKS URI, and specific path specifications for inclusion and exclusion. 

The configuration process is conducted using YAML files, known for their simplicity and user-friendly nature. This approach not only ensures the security of our microservices but also provides an intuitive and accessible means of configuration, aligning with ISTIO’s commitment to enabling composable architecture and user-friendly implementation practices.

Service-to-Service Authentication

Service-to-Service Authentication, also known as transport authentication, involves verifying the client connection to ensure secure communication. In this context, ISTIO provides mutual Transport Layer Security (mTLS) as a comprehensive API security solution for transport authentication.

The key component responsible for furnishing digital certificates based on the Secure Production Identity Framework for Everyone (SPIFFE) standards is Citadel. These digital certificates are assigned to each sidecar, commonly referred to as Envoy proxies, present in the Data Plane of the ISTIO architecture.

In the upcoming sections, a detailed exploration of the configuration process and the runtime execution of authentication will be elucidated. This discussion aims to provide a thorough understanding of how mTLS, facilitated by Citadel and adhering to SPIFFE standards, operates during both the configuration phase and the actual execution of service-to-service authentication within the ISTIO framework.

CONFIGURATION FLOW

To comprehend the distribution of digital certificates by the Citadel component for each pod within the Data Plane, we will explore the intricacies of integration flows. The next steps will highlight this process:

Citadel Observes Kubernetes API Server:

• Citadel actively monitors the Kubernetes API server, creating a Secure Production Identity Framework for Everyone (SPIFFE) certificate and key pair for each existing and new service account.
  
  
• This generated certificate and key pairs are stored as Kubernetes secrets by Citadel.
  
  

Mounting Certificates to Pods:

• Upon the creation of a pod, Kubernetes, in conjunction with Citadel, mounts the relevant certificate and key pair to the pod. This is achieved based on the pod's service account via a Kubernetes secret volume.
  
  

Automatic Certificate Rotation:

• Citadel vigilantly monitors the lifespan of each certificate and autonomously initiates certificate rotation by rewriting the Kubernetes secrets.
  
  

Pilot-Generated Naming Information:

• The pilot component generates secure naming information, precisely defining which service account or accounts can execute a particular service.
  
  
• Certain naming information is then transmitted to the sidecar Envoy by the pilot.
  

To sum it up, the comprehensive management of digital certificates within the ISTIO Infrastructure is orchestrated by the Citadel component. This centralized control not only streamlines the management of digital certificates but also serves as a pivotal point for intervention in the event of any certificate-related issues. 

The meticulous orchestration outlined in these steps contributes to the reliability and efficiency of ISTIO’s certificate management system.

AUTHENTICATION FLOW IN DATA PLANE

The authentication flow within the Data Plane for service-to-service authorization unfolds through the following steps, intricately relying on envoy (sidecar) features:

Outbound Traffic Rerouting:

• ISTIO directs outbound traffic from a client to the client's local sidecar Envoy.
  
  

Mutual TLS Handshake Initiation:

• The client-side Envoy initiates a mutual Transport Layer Security (TLS) handshake with the server-side Envoy.
  
  
• Simultaneously, during the handshake, the client-side Envoy performs a secure naming check to validate that the service account presented in the server certificate is authorized to operate the intended service.
  
  

Establishment of Mutual TLS Connection:

• Following successful authorization, the client-side Envoy and the server-side Envoy establish a mutual TLS connection under the supervision of ISTIO.
  
  
• ISTIO then facilitates the forwarding of traffic from the client-side Envoy to the server-side Envoy.
  
  

Traffic Forwarding to Server Service:

• Post-authorization, the server-side Envoy proceeds to forward the traffic to the server service through local Transmission Control Protocol (TCP) connections.
  
  

The intricate steps outlined in this flow underscore the integral role of envoy (sidecar) features in orchestrating a secure and authorized communication path within the Data Plane. The reliance on mutual TLS handshakes and secure naming checks ensures a robust and authenticated service-to-service interaction.

Key Insights

In essence, Microservices Architecture stands out as a prominent pattern in contemporary software development, acknowledged for its benefits and challenges. However, security implementation within this composable architecture presents notable challenges, including varied patterns and tools linked to specific programming languages and Developer experience best practices. 

Standardizing API security governance becomes crucial, and ISTIO, a service mesh architecture, emerges as a practical solution, offering centralized yet simplified security configurations, especially within Kubernetes. ISTIO provides a comprehensive approach, addressing challenges in Microservices security by offering end-user authentication through JWT and OpenID Connect, as well as service-to-service authentication using mTLS, digital certificates, and an effective API strategy.

The configuration and authentication flow within ISTIO contributes to a robust and centralized security framework for Microservices on Kubernetes, enhancing manageability ensuring a secure environment, and empowering your digital revolution.