Microservices Architecture And Microservices Security With Kerberos Authentication – A Comprehensive Guide !!
There is a new buzz in the coding world about the Microservices . Microservice is developed based on business features and deployed independently by automated deployment machinery.
There is less centralized management of Microservices that may be written in various programming languages and utilize diverse data storage technologies. In this post, we will explore all the details regarding the Microservices Architecture and security . So just sit back and proceed further .
Initially we will start by understanding the basic Microservices architecture and in the later sections, we will further look into the implementation of the Kerberos authentication process for the security of Microservices .
What Is Microservices ? (Definition Of Microservices !!)
Microservice architectural style is a method to create an application as a set of small services that runs its process and interact with lightweight mechanisms, usually an HTTP resource API .
In layman terms, let us understand Microservices in simple terms. You may consider any Microservices as a separate business entity, which further communicates with other Microservices to provide a well defined larger business outcomes .
For example , in Amazon we have separate Microservices handling orders to your cart , your wishlist, booking orders etc . Now for you, it seems that the complete Amazon site is a single e-commerce site.
But in reality , behind the scene, there are many Microservices that are working together to deliver a flawless shopping experience for you .
All these separate Microservices communicates by the means of API and HTTP requests. Also, each Microservices has its own data model to handle its own data . So in the above example we have separate wishlist Microservice , booking Microservice , orders Microservice etc to handle each process separately .
What Are The Application Types In General ? (Monolithic Vs Microservice applications)
Any application is broadly classified into two types:
i) Monolithic Architecture , where an application is built as a single unit.
ii) Microservices Architecture , where many applications (Microservices) handle a small portion of the functionality and data.
We will discuss both these types in detail. Let us understand each in brief now .
A Brief Overview Of The Monolithic Architecture
A monolithic application is built as a single unit, i.e., one big application in a single language that handles all of the functionality , logic etc. A load balancer distributes requests from the end user, across multiple machines, each running one instance of our application.
All logic for handling a request runs in a single process, allowing you to utilize the primary features of the language to divide up the application into classes , functions and namespaces .
The overall maintenance cost for set up and code modification (as application grows further) will be a major hurdle here . Also if any single application function or component fails, then the entire application goes down. There are many other reasons you should go ahead with the Microservices kind of architecture for your business .
Now its time to understand the Microservices architecture in detail . So without wasting any further time , let us dig deep inside it .
What Exactly Is The Microservices Architecture ?
Microservices are considered as the building blocks of modern applications . Big enterprise players such as Amazon , Netflix , Ebay etc have adopted Microservices. Services are
- Independently deployable
- Scalable
Each service offers a secure module boundary, allowing different services to be written in different programming languages. There are any advantages deploying Microservices architecture like easy deployment , quick fault detection , fast isolation of any infected process etc .
There are famous 3 C’s of Microservices which mainly include :
Componetize : Componentization of single application into multiple serviceable components is the most important activity. Best would be to start by defining a RESTful API to access this service, then plan and create an implementation using comfortable development language and platform
Collaborate : Communication among bigger teams becomes complex, which results in numerous mistakes and curbing the speed of development. Collaboration among teams focuses around API contracts and Technology standardization
Connect : The final delivery of an application requires more than the development of the constituent components. These components must be connected, the presentation layer and additional services must be layered in, then the completed application must be delivered to users. Given that Microservices must communicate using APIs.
Patterns In Microservices Architecture :
Now let us see in detail each of the patterns in the Microservices architecture .
API Gateway In Microservices Architecture !!
Microservices provide fine-grained APIs based on client needs. Each client needs to interact with multiple services to collect relevant information. For example, a payment client needs to fetch data from several services such as product, customer, and billing.
API Gateway takes care of the external traffic of coordinating with various services . The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client.
The API Gateway is liable for Protocol translation, Composition, and Request Routing . Insulates the clients (internal structure of the application). It provides a specific API to each client, reducing the number of round trips between the client and application .
Do You Know ?
The Netflix architecture includes an API Gateway that handles approximately 2 billion API edge requests daily, which are handled by about 600+ Microservices. Netflix has created a cloud-based IT architecture for deploying the same .
Communication In Microservices Architecture !!
In a microservices-based application, it is distributed across multiple services. Each service instance must interact with the other using an Inter-process communication (IPC) mechanism. The services can communicate within themselves, either through Messaging or Remote Procedure Invocation.
There are several interaction styles followed in Microservices :
One-to-one or One-to-many : In One to One style , every client request is processed by specifically one service instance. In One To Many type , each request is processed by several service instances.
Synchronous or Asynchronous : In Synchronous style , the client expects a timely response from the service and might even block while it waits. In Asynchronous style , the client does not block while waiting for a response, and the response is not necessarily sent immediately.
Inter Process Communication : The RPC based mechanisms attempt to make invoking a remote service look the same as calling a local service. And during failure, they are entirely different. Messaging makes these differences very explicit, so developers are not lulled into a false sense of security.
Service Registry In Microservices Architecture !!
Service Registry in Microservices is used to know about the available instances of a service . Service Registry acts as a database of services, their instances, and corresponding locations. Service instances are registered with the service registry on startup and deregistered on shutdown.
Clients of the service/router query the service registry to find the available instances of a service. Some of the famous service registries include – Eureka, Apache Zookeeper, Consul, etc.
Service instances have dynamically assigned network locations. Service instances change dynamically due to Auto-scaling, Failures, and Upgrades.
The client needs Service Discovery Mechanism to overcome this. There are two types of Service Discovery :
- Client side discovery
- Server side discovery
The clients take the onus and are responsible for determining the network locations of available service instances by querying a service registry. This is a straight forward approach.
When the number of consecutive request failures crosses a threshold. The circuit breaker trips for limited timeout period and all attempts to invoke the remote service fail immediately.
Data Management In Microservices Architecture !!
Data access is a little complex in Microservices architecture. This is because data owned by each microservice is private to that Microservice and can only be accessed through its API.
Data Encapsulation showcases that the Microservices are loosely coupled and can evolve independently of one another. Microservices often use different kinds of databases (a mixture of both SQL and NoSQL databases), so-called Polyglot persistence approach.
Service Deployment In Microservice Architecture !!
A Microservice-based application consists of tens or hundreds of services. Services are written in a variety of languages, frameworks, and each service acts as a mini-application on its own .
Each service instance must be offered with appropriate I/O resources, memory, and CPU. Also deploying services must be quick, cost-effective, and reliable .
Service Deployment is classified into three types :
1. Multiple Service Instances per Host Pattern (Run multiple service instances provisioned in one or more physical or virtual hosts)
2. Service Instance per Host Pattern (Here you package each service as a virtual machine (VM) image. e.g., Amazon EC2 AMI. Each service instance is a VM, that is launched using VM image)
3. Service Instance per Container Pattern (Here you will package the service as a (Docker) container image and deploy each service instance as a container)
Caching In Microservices Architecture !!
Cache is the capability to store data temporarily to lessen the loading times and I/O of a system. Caching helps in improving the performance of the system. The goal of caching in microservices is:
- Identifying what can be cached
- How to cache data for faster response
HTTP 1.1 has a set of headers that support caching. Cache-control provides a lot of attributes on caching for both responses & requests.
Responses include public, private, no-cache, no store, no transform, proxy revalidate, maxage that controls the level of caching done.
Security In Microservices Architecture !!
The security aspect, related to the identity of the requestor services to handle the request, is taken care by API Gateway. The API Gateway authenticates the user and transfers an access token (e.g., JSON Web Token) that securely recognizes the user in each request to the services.
The access token is issued upon successful authorization which is used for authenticating all requests. A user will get a token when a user logs into an application. This token will help other services to identify the user .
Microservices Chassis !!
Development of any new application, requires significant time to put in place, the mechanisms to handle cross-cutting concerns such as:
Externalized configuration – credentials, and network locations of external services such as databases and message brokers.
Logging – configuring of a logging framework (for audit trail) such as log4j or logback .
Health checks – to check the application status, a URL that a monitoring service can “ping” to determine the health of the application.
Metrics – track application performance measurements to know more about what and how the application is doing .
With Microservice chassis, it becomes effortless and quick to get started with developing a Microservice .
Observability For Microservices Architecture !!
Observability mainly focusses on the following aspects :
Application logging – Errors, warnings, information, and debug messages about action are tracked in the log file.
Application metrics – Gathers statistics about individual operations of each service and aggregates metrics in centralized metrics service, for reporting and alerting.
Audit logging – Records user activity in a database.
Exception tracking – Report all exceptions to a centralized exception tracking service that aggregates and tracks exceptions and notifies developers.
Distributed tracing – Each external request is assigned a Unique ID, which is passed to all services involved in handling the request and also included in application log messages.
Health check API – Returns the health of the service. A load balancer, service registry, or monitoring service can ‘ping’ this API to verify service instance availability.
So we are somewhat done explaining the complete Microservices architecture in detail . Now its time to explore the next important topic i.e. security in Microservices using Kerberos .
Why There Is Need Of Security In Microservices ?
Security indeed is a major aspect in considering any service into action within a large enterprise solution. As in Microservice , there are several small applications loosely coupled to each other , security is an inevitable factor for ensuring security .
Are you tired of traditional authentication mechanisms? Are you looking for a better method to authenticate your Clients? So if you are really bothered by the security of your network , then just read further .
Basics Of Security In Any Business Communication !!
Encryption is a mechanism by which you can convert data that has valuable information to trash. Yes, you read it right. Encryption converts information to something that is not usable unless you decrypt it.
Encryption is used to make sure that only an authorized user can get access to the information. Let us now see some types of encryption :
Symmetric Cryptography: This method uses a key that is used to convert information to trash.
It can be considered as a function that takes information as input and gives non-usable data as output. Problem with this approach is both the sender and receiver need to have the same key to encrypt and decrypt the data.
Asymmetric Cryptography: This method uses two different keys known as public and private keys, where any of the keys can be used for encryption and decryption. This method doesn’t require two parties to have the same key. Hence, it resolves the key sharing problem.
Authentication and Authorization In Encryption !!
Authentication is the process of verifying the identity of a user. Authorization specifies whether an authenticated user has the right to access the object in the system.
before we dig into the need Kerberos , we should understand why it exists in the first place . Definitely there should be some drawbacks in the traditional ways right ? .Let’s understand.
Traditional Methods Of Security !!
A user of the service sends his credentials such as username and password to the service provider for verification.
Service Provider receives credentials and verifies the identity of the user. If the user is valid, then he/she will be provided with resources that he/she has requested.
Vulnerabilities involved in this type of authorization :
Since a Service Provider and User are connected using a public network, Credentials sent by the user is accessible to all those who are connected to the network.
If a malicious user connected to the same network and is listening to network traffic can capture user’s credentials, then the user can use the same to fake authenticate himself/herself.
Not only sniffing or eavesdropping is a problem in Traditional Authentication Architecture, but also a user has to provide his credentials each time he wants to access a Resource. This is inconvenient and leads to weaker passwords.
Note : Resource Providers may store users passwords in an unencrypted format which leads to a privacy threat.
What Is Kerebros Authentication In Microservices Security ?
You have seen that transferring credentials over the network,frequent password requirement by the resource server and unencrypted password storage are some issues with traditional authentication flow .
There is a need of protocol which ensures Servers always store the password in an encrypted format and users don’t need to provide your password each time you request for a resource .
Kerberos is a network protocol designed to provide reliable and secure authentication over an insecure and open network where communication between the hosts may get sniffed.
Kerberos was developed at MIT during the mid 1980s . Kerberos ensures that users’ credentials must only be stored in an Authentication Server. Application Servers must not store client’s credentials .
With Kerberos administrator can disable a user account for all applications from a single point . Admin only needs to safeguard one Authentication Server .
With the implementation of Kerberos in Microservice , you can ensure the following aspects precisely :
1. Not only users but Resource/Application Servers also need to prove their identity to users. (Mutual Authentication)
2. On completion of the Authentication, server and client must be able to set up an encrypted connection, if they choose to do so
Various Terms You Should Know In Kerberos Authentication Concept !!
Before understanding the full concept of Kerberos , it is required to learn the basic terms used in this :
Kerberos Terms
1. Realm : Realm specifies an authentication administrative domain , it establishes boundaries among different domains. A user/service is said to be a part of a Realm if and only if it shares a secret (key/password) with Authentication Server of that realm .
2. Principal : Principal refers to the entries in the Authentication Server database , Principal will be associated with each service, user, and host of any realm .
3. Ticket : Ticket is used by the client (user/service/host) to verify its identity to Application Server . Tickets are issued by Authentication Server to the client and encrypted using key shared between Application Server and Authentication Server. Since the client doesn’t have the key, the client will not be able to view or change the Ticket .
4. Encryption : Kerberos encrypts every message that is transferred through the network, Kerberos uses private key encryption. Encryption key used in Kerberos is the hashed value of a user’s password .
5. Key Distribution Center (KDC) : The core of a Kerberos server is Key Distribution Center (KDC). It issues tickets required to access services . KDC is generally divided into three subparts:
- Database
- Authentication Server
- Ticket Granting Server
6. Session Key : Both users and services share secret key with KDC. User key is derived from their password. Service key is set by the administrator. These keys have a long life since they don’t need to be changed when work session changes.
7. Authenticator : Even though a ticket is encrypted, it still can be sniffed by a middleman and can be used for false authentication. Even though the ticket has an IP address of the client, it is not difficult to spoof IP address .
To make the protocol even secure, Session keys are introduced. So that an addition key which is only known to service and client (generated by KDC) is used with the request .
8. Replay Cache : Sending authenticator and tickets provide a good authentication mechanism, but it is still possible that the intruder may sniff tickets and authenticator, and can try to false authenticate himself.
To make sure one authenticator is associated with only one request, server (service provider) maintains a Replay Cache
9. Credential Cache : The client never stores user a password or the key, they are used to decrypt KDC replay and discarded right away .
It is necessary to store ticket and session key so that client doesn’t have to log in each time he requires some service. These are stored in a place called Credential Cache .
Now let us understand the real operation of Kerberos in Microservice .
Detailed Operation Of Kerberos In Any Microservice !!
I hope you already acquaint yourself with the basic terms used for Kerberos from the previous section . At this point, it is important to infer that Application Server never communicates with KDC. Service Tickets reach Application Server from the client accessing the service provided by the Server .
Steps Included In Kerberos Authentication Implementation In Microservice!!
Any Kerberos authentication flow must flow through following steps.
1. AS_REQ (Authentication Server Request) is the initial request sent by the client to Authentication Server.
2. AS_REP (Authentication Server Reply) is the reply sent by the Authentication Server to the client it consists of TGT and Session Key.
3. TGS_REQ (Ticket Granting Server Request) is sent(TGT) by the client to TGS to obtain a service ticket.
4. TGS_REP (Ticket Granting Server Reply) is a replay sent by TGS consists of Service Key and Service Session Key.
5. AP_REQ(Application Server Request) is the request sent by the client to the Application Server requesting a particular service. It consists of an Authenticator and the Service Ticket.
6. AP_REP(Application Server Reply): If mutual authentication is necessary client requests for this so that Application Server can prove its identity.
Authentication Server Request In Kerberos Authentication Process !!
AS_REQ is the initial authentication request sent by the client(kinit) to Authentication Server asking for Ticket Granting Ticket.
AS_REQ will look like this,
AS_REQ = ( princ^{Client}, princ^{Service} , IP_list , Lifetime )
Where,
princ^{Client} represents the Principal of Client (requesting party) and the princ^{Service} represents the service to which the ticket being asked for.
IP_list is the list of possible IP addresses from where this ticket can be used.
Lifetime is the maximum lifetime for the ticket to be issued
Authentication Server Reply
On receiving AS_REQ, Authentication Server checks for the existence of client and service principal, if it doesn’t exist then an authentication error is thrown otherwise.
- It’ll create a Session Key, a secret shared between TGS and the client({sk}^{tgs}).
- It creates a TGT by adding user’s and service principal, IP_List (these three pieces of information copied from AS_REQ),KDC date time in timestamp format, and the session key ({sk}^{tgs}).
Authentication Server Reply
Finally, the server will send an authentication reply containing,
- TGT encrypted using service secret key({k}^{tgs}).
- Service principal, lifetime, timestamp, and the session key encrypted using the secret key of the user secret key ( {k}^{user}).
Once the client receives the AS_REPL,
- The client will be asked to enter his password.
- Password salt will be concatenated and the key will be calculated.
- If the user is genuine he will be able to decrypt the part of AS_REPL encrypted using user’s secret key({k}^{user}).
- Then the client extracts the session key ({sk}^{tgs}) and will be used to encrypt further communications.
TGS Request
Once the client receives the AS_REPL,
- The client will be asked to enter his password.
- Password salt will be concatenated and the key will be calculated.
- If the user is genuine, he/she will be able to decrypt the part of AS_REPL encrypted using the user’s secret key({k}^{user}).
- Then the client extracts the session key ({sk}^{tgs}) and will be used to encrypt further communications.
On receiving TGS_REQ Ticket Granting Server checks for the existence service principal in KDC DB. If it does,
- It decrypts TGT({ TGT }{k}^{tgs}) and retrieves the session key ({sk}^{tgs}) which will be used to decrypt the Authenticator.
- To issue Service Ticket following criteria should be met. TGT is not expired. The Authenticator is not available in Reply Cache and is not expired
Some Prerequisites Before You Start Implementing Kerberos Authentication !!
You must have noticed from Kerberos flow topic that Kerberos operates as a network protocol and usually works inside a domain, hence it is necessary to have name resolution(DNS) setup before proceeding with Kerberos.
If you don’t have DNS set up, you can add all hostname IP mapping to /etc/hosts .
You also must have come across timestamp during Kerberos authentication and application server communication, hence it is necessary to synchronize server, client and application server time (Protocols such as NTP can be used).
You may also need to configure your firewall to allow access to Kerberos
Why To Use Microservices – Final Wrap Up !!
From the above few sections it is indeed clear that using and deploying separate Microservice makes any big enterprise system easier to repair , troubleshoot (in case of any emergency) and more secure .
Whenever we want to upgrade any individual Microservice ,we have to just modify the code for that specific Microservice rather altering the code for the whole enterprise application altogether (a tedious and time consuming task no doubt) .
Breaking a full application into several small Microservice applications, also allow us to focus on each separate process as unique business requirement (improves efficiency and business productivity) .
We can further use different language for coding and various other tools to get the desired outcomes . As long as different Microservices can able to interact with each other , it doesn’t matter at all the code and databases they separately using .
Hope you really liked this post regarding Microservices Architecture and the Kerberos based Micrservice Security . Stay tuned for more interesting stuff in this series .
Aric is a tech enthusiast , who love to write about the tech related products and ‘How To’ blogs . IT Engineer by profession , right now working in the Automation field in a Software product company . The other hobbies includes singing , trekking and writing blogs .