DEV Community: Zelar

From Legacy to Innovation: How APIs are Redefining Digital Experiences and Growth

Zelar — Mon, 30 Sep 2024 08:51:48 +0000

Why APIs are Key to Digital Transformation

APIs, (application programming interfaces), are much more than just technical connectors in the rapidly changing digital world of today. They are essential in helping companies to reintegrate fragmented systems, spur innovation, and react quickly to shifts in the market. APIs enable organizations to reduce complexity, maintain lean operations, and fully utilize the value of their data by allowing data to be shared and connected with ease.

As popularly said "No AI without API." This demonstrates how important APIs are for facilitating the full potential of cutting-edge technology like artificial intelligence (AI) as well as for linking disparate systems.

Key Benefits of APIs in Driving Digital Transformation

1: Enabling Seamless Integration of Legacy Systems
Fact: APIs bridge legacy systems with modern tech without costly overhauls.
Example: Walmart used APIs to link its legacy infrastructure to cloud services, improving e-commerce and operations.

2: Driving Innovation Through Ecosystem Expansion
Fact: APIs open doors for external collaboration and faster innovation.
Example: Salesforce allows developers to create custom apps through its API ecosystem, expanding capabilities without in-house development.

3: Enhancing Customer Experience
Fact: APIs provide seamless, personalized experiences across devices and platforms.
Example: Netflix relies on APIs to keep user data in sync across different devices to deliver a seamless experience of streaming.

4: Facilitating Agility and Faster Time-to-Market
Fact: APIs accelerate product development, reducing time-to-market.
Example: Uber scaled rapidly by leveraging APIs, opting to integrate services like Google Maps and third-party payment processors instead of building their own. This approach enabled them to focus on core innovations and expand more efficiently.

5: Empowering Data-Driven Decision Making
Fact: APIs unlock real-time data for analytics, improving decision-making.
Example: In building its industrial Internet of Things (IoT) platform, Predix, to predict equipment failures and optimize performance, General Electric (GE) - a global leader in sectors like energy and aviation—relied heavily on APIs to drive innovation and efficiency.

6: Supporting a Microservices Architecture
Fact: APIs enable microservices, improving flexibility and scalability.
Example: Spotify uses microservices backed by APIs for faster feature releases and smoother scalability.

Further API-Driven Enhancements

1. API Monetization: Generating Novel Income Sources:
APIs have the potential to generate income in addition to promoting internal improvements. Businesses can develop new business models and increase revenue by providing APIs to outside organizations.
Example: Twilio made a billion dollars by charging for its communication APIs, which enabled other businesses to incorporate its services into their own platforms.

2. Enhancing Security through API-First Design:
Businesses are often concerned about security, especially when exchanging data. Employing an API-first strategy enables businesses to incorporate robust protocols like token-based authentication, OAuth, and encryption right into the design process.
Example: Financial institutions depend on API-first designs to guarantee safe and legal system transactions.

3. Enabling AI and Machine Learning Integrations:
APIs are essential for incorporating machine learning and AI into corporate processes. They make it possible for AI-driven systems and legacy apps to exchange data seamlessly, which leads to more intelligent automation and better user experiences.
Example: IBM Watson and Google AI provide APIs that allow easy integration of AI into applications, enabling businesses to adopt machine learning without building complex systems.

4. Facilitating Compliance and Governance:
APIs are essential to an organization's ability to stay in compliance with industry rules. APIs guarantee that data integrity is safeguarded, audit logs are kept up to date, and access regulations are adhered to by permitting restricted access to sensitive data.
Example: Healthcare institutions can safely exchange patient data while adhering to HIPAA laws by using APIs.

5. Reducing Technical Debt through API-Driven Modernization:
Upgrading old systems all at once can be expensive and unsafe. With APIs, companies may integrate new technologies with pre-existing systems gradually, lowering technological debt over time. With this method, changes can be made gradually without interfering with running business operations.
Example: Banks employ modernization plans powered by APIs to prolong the life of their core banking systems and simultaneously implement newer technologies.

Conclusion: APIs as the Key to Digital Success
APIs are the foundation of the contemporary digital transformation; they are more than just connectors. APIs provide businesses seeking to stay ahead in the rapidly evolving digital ecosystem of today a wealth of opportunities, from facilitating smooth system interfaces to spurring innovation and revenue. Businesses may increase security and ensure compliance while reducing technical debt, fostering agility, improving customer experiences, and opening new opportunities by embracing APIs.

Zelarsoft is a trusted partner, specializing in Kong API Gateway solutions and cloud services. As an official Kong partner, we offer end-to-end consulting, implementation, and licensing services to help businesses maximize their API management capabilities. Our Kong licensing solutions ensure that organizations can leverage the full potential of Kong’s enterprise-grade features, including enhanced security, traffic management, and performance optimization.

In addition to Kong's powerful API Gateway, we provide seamless integration with cloud platforms like Google Cloud and AWS, delivering cost-effective and scalable solutions. Our expertise ensures businesses can simplify their infrastructure, maintain compliance, and improve operational efficiency. Whether you're looking to secure your APIs, scale your services, or future-proof your IT environment, Zelarsoft offers tailored solutions that accelerate innovation and reduce complexity.

Schedule a complimentary consultation with Zelarsoft to assess your Kong API Gateway setup and optimize your API management strategy for enhanced security, scalability, and performance.

For more information: https://zelarsoft.com/
Email: info@zelarsoft.com
Phone: 040-42021524 ; 510-262-2801

Integrating a Developer Portal with Kong Admin API: A Deep Dive into a Hierarchical Multi-Tenant Solution

Zelar — Mon, 15 Jul 2024 07:12:42 +0000

This document outlines a technical solution of how to implement a developer portal with Kong Admin API to support the multi-tenanted system. This solution is suitable for a customer who needs to have efficient API management for multiple partners in a single Kong deployment and workspace.

Architectural Overview:
Our solution leverages Kong’s powerful features to design a reliable and secure system. The architecture comprises three main components:

1.Kong Gateway: Acts as the API gateway, controlling traffic flow, authentication, and rate limiting.
2.Kong Admin API: Provides an interface for interacting with Kong’s configuration and allowing for the creation, modification, and deletion of services, routes, consumers, and plugins.
3.Custom Developer Portal: A customized web application for partner developers to manage themselves and for customer administrators to manage the partners.

Hierarchical Role Management:
We will implement a three-tiered role-based access control system:

1.Kong Admin: Has full access to the system, including the creation and administration of customer admins.
2.Customer Admin: Controls partner developers and their API usage within their organization including creating, editing and deleting partner developer accounts and manage API subscriptions.
3.Partner Developer: Uses the APIs provided by the customer. They can see what APIs are available, signs up for them, and deal with API keys.

Authentication and Authorization:
Kong Admin API: Protected by Basic Authentication, with credentials used by the custom developer portal for all interactions.

Custom Developer Portal:
Login: Once a user logs in successfully, the portal saves session information (for example, in the form of a JWT token) and uses it for further communication with the Kong Admin API.
Customer Admin & Partner Developer Differentiation: After authentication, the portal determines the user’s role and displays the interface and features based on the role.

API Loopback Configuration:
To enable the developer portal to manage Kong's configuration, we will utilize an API loopback mechanism:

1. Proxy the Kong Admin API: Expose the Kong Admin API through a separate proxy URL to enhance security by concealing the real Admin API endpoint.
2. Define Services and Routes: Configures services and routes in Kong to handle the requests coming to the proxy URL.
3. Apply Plugins:
CORS: Enable CORS on these routes to allow the developer portal (which is a different origin) to access Kong Admin API.
Request Transformer: Modify requests to meet the data integrity and confidentiality requirements. This could include adding headers, changing paths or even modifying the body of the request.

Implementation Details:

1. User Onboarding and Role Assignment:
- Kong Admin:Sets up Customer Admin accounts in the Kong Manager and provides the initial login credentials.
- Customer Admin: Self-enrolls to the developer portal using the credentials shared by the Kong Admin and manags Partner Developer accounts through the portal.
- Partner Developer: Self-enrolls on the developer portal, authorized by the Customer Admin.

2. Custom Developer Portal Development:
Use an appropriate frontend framework (for example, React, Angular, Vue. js) to Customise the in-built the developer portal.

Key functionalities include:
- User Authentication: Secure login, logout, and session management.
- Role-Based Views: Different views and actions depending on the role of the user (Kong Admin, Customer Admin, Partner Developer).

3. API Management:
- Customer Admin: To view, modify, and control the API access for their Partner Developers.
- Partner Developer: View and search through lists of available APIs, subscribe to APIs, access documentation, and manage API keys.
- Kong Admin API Integration: The integration majorly helps with portal developers’ management from custom portal itself instead of exposing the admin application externally.

API Loopback Configuration:
1. Configure Proxy: Configure a reverse proxy (for example, Nginx) to redirect requests to the Kong Admin API through a specific endpoint.
2. Create Kong Service: Create a Kong service that corresponds to the Admin API to be proxied.
3. Create Kong Route: Make a route that will direct any request made to the proxy URL to the Kong Admin API service.
4. Apply Plugins:
> Include the CORS plugin to the route and set the allowed origin, headers, and methods.
> Develop a Request Transformer plugin to adjust requests for security and standardization purposes.

Advantages of this Solution:
1.Centralized Management: Single Kong deployment and workspace ease management and offer a holistic view of all partners and APIs.
2.Enhanced Security: Hierarchical roles, Basic Authentication for the Admin API, and proxying the Admin API also improve the security.
3.Improved Developer Experience: The custom developer portal provides a simple way for developers to discover, consume, and manage APIs.
4.Scalability and Flexibility: It is easy to extend the solution to support more partners and APIs as the system grows.
This approach offers a clear and secure plan for integrating a developer portal with Kong Admin API.

By following security best practices and utilizing Kong’s capabilities, this solution provides a scalable and user-friendly platform for API and partner management.

Citations:
[1] https://docs.konghq.com/gateway/latest/admin-api/
[2] https://curity.io/resources/learn/kong-dev-portal/
[3] https://cloudentity.com/developers/howtos/enforcement/kong/
[4] https://www.youtube.com/watch?v=nuvdTb9XlkU

For more information: https://zelarsoft.com/
Email: info@zelarsoft.com
Phone: 040-42021524 ; 510-262-2801

Pilot to Full Adoption

Zelar — Thu, 11 Jul 2024 12:07:08 +0000

With the goal of increasing developer productivity and optimizing coding procedures, our customer set out to integrate GitHub Copilot throughout their entire company. By using a disciplined strategy, 1,600 developers were eventually engaged and the pilot phase to full adoption was smoothly transitioned. This article highlights important tactics and lessons acquired while outlining the project's phases, procedures, and results.

Project Overview:
Project: GitHub Copilot Adoption Delivery
Duration: 16 weeks
Participants: 1,200+ targeted developers

Project Phases:

1. Pilot Phase:
Duration: 4 weeks
Participants: 37 Influencers

The first round of the pilot program concentrated on a small cohort of 37 prominent developers who would advocate for GitHub Copilot's implementation inside the company. These influencers were essential in spreading the word about the tool, giving suggestions, and serving as first responders for inexperienced users.

Activities:

i. Workshops & Demo Sessions: Designed with backend and frontend developers in mind, we conducted practical workshops and demo sessions.
ii. Mechanisms of Feedback: Frequent feedback sessions, surveys, and check-ins are used to improve the tool's deployment and support system.

2. Adoption Phase
Duration: 12 weeks
Participants: 1,200+ Developers

After the successful pilot, four iterations of the adoption phase involving developers were implemented. This staged strategy made it possible to scale gradually, quickly resolve any issues, and guarantee a smooth adoption process.

Activities:

i. Workshops: Ongoing practical sessions addressing best practices, real-world applications, and capabilities of GitHub Copilot.
ii. Structure of Support: A strong support system with channels set aside for questions and issues was established.

Strategies for Success:
1. Promoting Adoption:

Leveraged the influence of pilot participants to drive adoption among their peers.
Regular feature refresh workshops to keep users updated and engaged.

2. Feedback and Continuous Improvement:

Actively sought feedback to refine training materials and support mechanisms.
Incorporated user suggestions to enhance the tool’s usability and relevance.

3. Comprehensive Training:

Conducted targeted workshops focusing on different development roles and tasks.
Provided practical, hands-on sessions to ensure users could effectively utilize GitHub Copilot in their daily workflows. Outcomes

Developer Satisfaction:

High acceptance rate with positive feedback on productivity gains and time savings.
Enhanced coding efficiency and reduced manual effort through AI-assisted development.

Productivity and Time Savings

Significant improvement in code quality and development speed.
Developers reported quicker comprehension of codebases and faster implementation of new features.

Acceptance Rate

Overwhelmingly positive Net Promoter Scores from pilot participants, paving the way for full adoption.

Conclusion:

Structured, progressive adoption tactics work, as demonstrated by the GitHub Copilot Adoption Delivery project. Through active feedback-seeking, thorough training, and engagement with key influencers, we successfully incorporated GitHub Copilot into the organization's development processes. This project raised the bar for future technological adoptions while also increasing developer productivity.

Future Outlook:

The effective implementation of GitHub Copilot has created opportunities for additional improvements to development tools and procedures. We're excited to carry on our collaboration and investigate fresh approaches to promote efficiency and creativity. The present case study functions as a model for analogous endeavors, elucidating the significance of strategic planning, ongoing enhancement, and user involvement in accomplishing triumphant technology adoption.

Zelar is a cloud-native consulting company specializing in modernizing legacy systems, enhancing DevOps culture, and accelerating code releases. Our expertise helps businesses significantly increase technical productivity and save on engineering resources. Additionally, we can assist you in adopting GitHub to streamline your development workflows and improve collaboration.

For more information: https://zelarsoft.com/
Email: info@zelarsoft.com
Phone: 040-42021524 ; 510-262-2801

Custom plugin development with an emphasis on RSA/HMAC encryption

Zelar — Wed, 19 Jun 2024 09:39:05 +0000

By Venkata Reddy Bhavanam
Author LinkedIn:https://www.linkedin.com/in/venkatareddybhavanam/

Role of Zelar:

Zelar developed a custom Kong plugin to enhance the client's security. The plugin integrated RSA encryption for robust data integrity and authentication and was adapted to support the client's unique signing string format. By modifying the open-source plugin code, Zelar seamlessly integrated the solution into the client's ecosystem, meeting their specific security requirements without disrupting ongoing operations.

About client:

The client, a leading digital bank in Indonesia, manages vast data critical to its operations, requiring intricate transformations across digital platforms. This process was time-consuming and prone to errors. By leveraging advanced technology and a customer-centric approach, the bank enhances its services, ensuring efficient and secure financial solutions while driving digital transformation in the Indonesian banking industry.

Problem Statement:

Need for Enhanced Security: The customer needed a solution that was not only covered by the current capabilities of Kong’s HMAC plugin but also covered the RSA encryption. This was mandatory in order fulfil their particular security requirements that use the asymmetric encryption methods.
Custom Signing String Format: The HMAC plugin was not capable of supporting the customer's unique signing string format that uses a different separator and specific attributes, which are vital for the security processes of the company.

Solution Provided:

Custom Plugin Development:

RSA Encryption Implementation: A custom plugin was created to include RSA encryption, providing secure and verifiable data integrity and authentication through a public/private key mechanism.
Adaptation to Custom Signing Formats: The custom plugin was tailored to fit the client's unique signing string format, including specific separators and attributes. It was maximally customized to be compatible with the client's security infrastructure and protocols.

Implementation:

The solution was to alter the open-source plugin code from the base of the GitHub repository of Kong to incorporate the required features. This method was effective, utilizing already available resources for that and the integration with Kong’s ecosystem was smooth.

Outcome:

The execution of the custom plugin has been successful in meeting the client’s specific security requirements, thus allowing them to keep the data security and integrity high level across their applications. The feedback showed that the solution worked perfectly and did not interfere with the present activities.

For more information: https://zelarsoft.com/

Kong Plugin Development: Local Development and Installation on Your Laptop/VM

Zelar — Mon, 10 Jun 2024 07:47:51 +0000

By Venkata Reddy Bhavanam
Author LinkedIn:https://www.linkedin.com/in/venkatareddybhavanam/

Kong is a popular, lightweight, fast, and flexible cloud-native API gateway. One of the key benefits of using Kong is its ability to extend the core functionality with the help of plugins. Kong provides many inbuilt plugins out of the box, but we are not limited to them. One can develop a custom plugin for their use case and inject it into the request/response life cycle.

Kong API Gateway (image Credits — KongHQ):

Kong is a Lua application running on top of Nginx and OpenResty. So, it allows building custom plugins natively using Lua. Writing custom plugins in other languages like Go, Javascript, and Python is also possible.

Kong can be installed in several ways. You can install Kong in a VM, Docker, or Kubernetes cluster.

This blog doesn’t aim to teach you how to write a custom plugin but how to install a custom plugin in a VM-based mode of Kong installation. If you are interested in how to write a custom plugin, please check out the Kong guides on plugin development.

Ideally, you’d use Pongo for custom plugin development. Once the development is complete, you can use one of the following methods to deploy the plugin based on your mode of Kong installation.

At a high level, a Kong plugin will have two files:

1.handler.lua: This is where we write Lua functions that get called during different phases of the request/response life cycle. These are maps to Nginx worker life cycle methods.

2.schema.lua: This is where we define the plugin configuration as schema(A Lua table), add some validations, provide default values, etc.

For this example, we’ll take a simple plugin that returns the version of the plugin as a response header. Below is the code for handler.lua

local plugin = {
  PRIORITY = 1000, -- set the plugin priority, which determines plugin execution order
  VERSION = "0.1", -- version in X.Y.Z format. Check hybrid-mode compatibility requirements.
}

function plugin:init_worker()
  kong.log.debug("saying hi from the 'init_worker' handler")
end

-- runs in the 'access_by_lua_block'
function plugin:access(plugin_conf)
  kong.service.request.set_header(plugin_conf.request_header, "this is on a request")
end

-- runs in the 'header_filter_by_lua_block'
function plugin:header_filter(plugin_conf)
  kong.response.set_header(plugin_conf.response_header, plugin.VERSION)
end

return plugin

and the schema.lua

local typedefs = require "kong.db.schema.typedefs"

local PLUGIN_NAME = "api-version"

local schema = {
  name = "api-version",
  fields = {
    { consumer = typedefs.no_consumer },  -- this plugin cannot be configured on a consumer (typical for auth plugins)
    { protocols = typedefs.protocols_http },
    { config = {
        type = "record",
        fields = {
          { request_header = typedefs.header_name {
              required = true,
              default = "Hello-World" } },
          { response_header = typedefs.header_name {
              required = true,
              default = "Bye-World" } },
        },
        entity_checks = {
          { at_least_one_of = { "request_header", "response_header" }, },
          { distinct = { "request_header", "response_header"} },
        },
      },
    },
  },
}

return schema

Deploying a custom plugin on a VM:

Please check this out to install the Kong gateway on Ubuntu. Once the installation is complete, ensure you can access the gateway at http://localhost:8000

Install the API-version plugin:

From the plugin folder, hit luarocks make

The default location for the Kong configuration is located at /etc/kong/kong.conf To tell Kong we want to install a custom plugin, add the plugin name to plugins config variable so that it looks like plugins=bundled,custom-plugin-name . In our case, it will be: plugins=bundled,api-version

And then restart Kong, kong restart -c /etc/kong/kong.conf
Once Kong is reloaded, the plugin should appear in the list of available plugins.

Installed custom plugin
We can enable the plugin globally or on a particular service/route.
Let’s create a service, route, and apply the plugin to the service to see it in action. We can create all these through the Kong manager UI, but we’ll use HTTPie to create these through the terminal.

http :8001/services name=mockbin url=https://mockbin.org Kong-Admin-Token:password
http -f :8001/services/mockbin/routes name=mock-route paths=/echo Kong-Admin-Token:password
http -f :8001/services/mockbin/plugins name=api-version Kong-Admin-Token:password

Now, if we request the /echo route, we can see the custom header that returns the plugin version in the response

http :8000/echo --headers
HTTP/1.1 200 OK
Bye-World: 0.1
...

That’s how a custom plugin can be installed in a VM-based Kong installation. In the next post, we’ll see how to install a custom plugin through Docker and Kubernetes.

For more information: https://zelarsoft.com/

Installing a Custom Plugin in Docker: Kong Plugin Development

Zelar — Tue, 04 Jun 2024 07:37:47 +0000

By Venkata Reddy Bhavanam
Author LinkedIn:https://www.linkedin.com/in/venkatareddybhavanam/

This is the second post on installing a custom plugin in Kong API Gateway. Please check out the 1st post if you need a quick introduction to Kong and how to install a custom plugin in a VM.
In this post, we’ll learn how to install a custom plugin in Docker.

We’ll use the same custom plugin code as we used in the previous post.

Kong Plugin Development

Copying the code over here for completeness. The folder structure:

api-version/ ├── handler.lua └── schema.lua

The plugin name api-version and the contents of schema.lua

local typedefs = require "kong.db.schema.typedefs"

local PLUGIN_NAME = "api-version"

local schema = {
  name = "api-version",
  fields = {
    { consumer = typedefs.no_consumer },  -- this plugin cannot be configured on a consumer (typical for auth plugins)
    { protocols = typedefs.protocols_http },
    { config = {
        type = "record",
        fields = {
          { request_header = typedefs.header_name {
              required = true,
              default = "Hello-World" } },
          { response_header = typedefs.header_name {
              required = true,
              default = "Bye-World" } },
        },
        entity_checks = {
          { at_least_one_of = { "request_header", "response_header" }, },
          { distinct = { "request_header", "response_header"} },
        },
      },
    },
  },
}

return schema

Contents of handler.lua:

local typedefs = require "kong.db.schema.typedefs"

local PLUGIN_NAME = "api-version"

local schema = {
  name = "api-version",
  fields = {
    { consumer = typedefs.no_consumer },  -- this plugin cannot be configured on a consumer (typical for auth plugins)
    { protocols = typedefs.protocols_http },
    { config = {
        type = "record",
        fields = {
          { request_header = typedefs.header_name {
              required = true,
              default = "Hello-World" } },
          { response_header = typedefs.header_name {
              required = true,
              default = "Bye-World" } },
        },
        entity_checks = {
          { at_least_one_of = { "request_header", "response_header" }, },
          { distinct = { "request_header", "response_header"} },
        },
      },
    },
  },
}

return schema

Building the docker image:
We’ll take a base Kong image, add the plugin(and dependencies, if any), and use the final image. The Dockerfile

FROM kong/kong-gateway:3.2.2.1

**USER root**

# luarocks install dependency-name # to install any dependencies for cusotm plugin
RUN mkdir /usr/local/share/lua/5.1/kong/plugins/api-versionCOPY ./api-version /usr/local/share/lua/5.1/kong/plugins/api-version

Here, we are taking Kong base image kong/kong-gateway:3.2.2.1 and adding our plugin code.

We can now build it and run it with the following:

docker build -t kong-demo .
docker run -d --name kong-demo \
  -p "8000-8001:8000-8001" \
  -e "KONG_ADMIN_LISTEN=0.0.0.0:8001" \
  -e "KONG_PROXY_LISTEN=0.0.0.0:8000" \
  -e "KONG_DATABASE=off" \
  -e "KONG_LOG_LEVEL=debug" \
  -e "KONG_PLUGINS=bundled,api-version" \
  kong-demo

As you can see, we specify the custom plugin name along with the bundled plugins using KONG_PLUGINSenvironment variable.

Kong can be run either in DB mode using Postgres (and Cassandra, but it will be deprecated) or DB Less mode. We’ll use db-less mode and the following declarative config to create a service, route, and apply the plugin for this demo.

config.yaml
_format_version: "3.0"
_transform: trueservices:
  - name: demo
    url: https://mockbin.org
    plugins:
      - name: api-version
    routes:
      - name: demo-route
        paths:
          - /echo

Create the config with an API call to the admin API.

curl -X POST http://localhost:8001/config -F config=@config.yaml

Verify the custom plugin works by visiting the proxy URL. We’ll use HTTPie

http :8000/echo --headers
HTTP/1.1 200 OK
Bye-World: 0.1
...

That’s it. In the next post, we’ll see how to install the custom plugin in Kubernetes.

For more information: https://zelarsoft.com/

Installing Custom Plugins in Kong API Gateway on Kubernetes: Helm Deployment in Hybrid Mode

Zelar — Mon, 27 May 2024 11:14:57 +0000

By Venkata Reddy Bhavanam
Author LinkedIn: https://www.linkedin.com/in/venkatareddybhavanam/

This is the 3rd post on installing custom plugins in Kong API Gateway. Please check out the first post for a quick introduction to Kong and installing a custom plugin in VM mode.

In this post, we’ll learn how to install a custom plugin deployed using Helm in Hybrid mode in Kubernetes, but this should also work in other modes of deployment in Kubernetes.

A custom plugin can be installed in Kong and deployed in Kubernetes in two ways.

1.Building a custom image by adding the plugin code to the Kong base image. This will be useful when our plugin needs a dependency at the OS level.

2.Adding the plugin as k8s ConfigMap or Secret. This is probably the easiest of two, as we don’t have to maintain the image in a custom container registry.

For #1, you can check how we can build the image in the last post of this series. Once the image is created, assuming the Kong gateway is deployed using helm, we can add the updated image with the tag in the values-cp.yaml and values-dp.yaml

We’ll use the same plugin api-version that we used in the last post.

First, we must create a Kubernetes secret for pulling the custom Kong image from our private docker registry. Assuming we have our image in GHCR, we can do the following:

kubectl create secret docker-registry your-secret-name-to-be-able-pull-image-from-cr --docker-server=ghcr.io --docker-username=your-user --docker-password=your-passwrod --docker-email=your-email -n your-namespace

Then, update the values-cp.yaml and values-dp.yaml With the following values:

repository: ghcr.io/zelarhq/kong/kong-gateway
tag: "3.2.2.1.api-version.01" # Should change this image as per company standards, refer to supported image tags https://hub.docker.com/r/kong/kong-gateway/tags
pullSecrets:
  - your-secret-name-to-be-able-pull-image-from-cr

env:
  plugins: "bundled,api-version"

...

And upgrade CP and DP with:

helm upgrade --install kong-cp kong/kong --namespace kong-enterprise -f values-cp.yaml
helm upgrade --install kong-dp kong/kong --namespace kong-enterprise -f values-dp.yaml

To enable the plugin, it should appear in the Kong Manager under the Plugins section.

For #2, create a k8s Secret,

kubectl create secret generic -n <namespace_name> kong-plugin-api-version --from-file=kong-plugin-api-version

OR a ConfigMap

kubectl create configmap kong-plugin-api-version --from-file=kong-plugin-api-version -n <namespace_name>

Update the values-cp.yaml and values-dp.yaml files with the following content:

Plugins:

secrets: #configMaps -> if using config map
  - name: kong-plugin-api-version
    pluginName: api-version

And upgrade CP and DP with:

helm upgrade --install kong-cp kong/kong --namespace <your-namespace> -f values-cp.yaml
helm upgrade --install kong-dp kong/kong --namespace <your-namespace> -f values-dp.yaml

For more information: https://zelarsoft.com/

Simplifying Distributed Applications with Multi-Zone Kuma Service Mesh Deployment

Zelar — Mon, 20 May 2024 09:20:11 +0000

By Amrutha Paladugu
Author LinkedIn: https://www.linkedin.com/in/amrutha-paladugu/

In the exciting world of distributed applications, juggling network connectivity and security across various environments can be quite a task. But fret not! Kuma, a vibrant open-source service mesh, comes to the rescue with its robust capabilities for managing and safeguarding communication between services. It simplifies the complexity of managing distributed systems and enables developers to focus on building applications without worrying about network-related challenges.

So, buckle up as we dive into the thrilling adventure of deploying a multi-zone global control plane using Kuma and the incredible Kubernetes platform. The multi-zone deployment allows you to distribute your control plane across multiple regions or availability zones, ensuring high availability and resilience.

The Bigger Picture:

The underlying logic of the Kuma multi-zone deployment revolves around establishing a distributed control plane architecture with global and zonal control planes.

• The global control plane is the central authority for the entire service mesh. It manages the overall configuration and policies that apply across all zones.
• Zonal control planes (CP) are deployed in specific zones, such as regions or availability zones. Each zonal CP connects to the global control plane to synchronize information. Zonal CPs provide local processing and handle local traffic efficiently.
• Cross-zone communication is enabled through the global control plane, which manages global policies and synchronizes information between zones.

The multi-zone mesh deployment process involves the following steps:

• Installing Kubernetes and Kumactl for cluster management and interaction with the control plane
• The global control plane is deployed using Helm, along with PostgreSQL for configuration storage
• Zonal control planes are installed on separate Kubernetes clusters, connected to the global control plane using the KDS (Kuma Discovery Service)
• Mesh configuration is enabled by labeling namespaces and deploying applications within those namespaces
• Cross-zone communication is facilitated by configuring the ZoneIngress and testing connectivity between zones.

Step 1: Install K8s and Install kumactl

The first step is to install Kubernetes (K8s). We are exploring the scenario where Kuma Service Mesh runs on top of Kubernetes, so we need a Kubernetes cluster to deploy our control plane.

To install a K3s cluster, run the following commands:

curl -sfL https://get.k3s.io | sh - sudo chmod 644 /etc/rancher/k3s/k3s.yaml mkdir ~/.kube sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config

Next, we must install the kumactl command-line tool, which interacts with the Kuma control plane.

To install kumactl, run the following commands:

curl -L https://kuma.io/installer.sh | VERSION=2.3.0 sh - cd kuma-2.3.0/bin PATH=$(pwd):$PATH

Step 2: Deploy a Multi-Zone Global Control Plane:

We will deploy the global control plane on the Kubernetes cluster (this could be on a VM or any cloud) following the steps below:

Step 2.1: Create the Namespace:

Create a Kubernetes namespace for the Kuma system:

kubectl create ns kuma-system

Step 2.2: Install PostgreSQL using Helm:

Use Helm to install PostgreSQL, which is required for storing Kuma's configuration:

helm repo add bitnami https://charts.bitnami.com/bitnami helm install my-postgresql bitnami/postgresql - version 12.5.8 -n kuma-system

Note the database name, password, user, and host read-write (RW) for later use.

Step 2.3: Define Kubernetes Secrets Manifest

Create a secrets.yaml file to store sensitive information required for connecting to the PostgreSQL database:

apiVersion: v1 kind: Secret metadata: name: your-secret-name type: Opaque data: POSTGRES_DB: <Postgres-DB-name> POSTGRES_HOST_RW: <Postgres-host> POSTGRES_USER: <Postgres-user> POSTGRES_PASSWORD: <Postgres-password>

Replace the placeholders with the corresponding base64-encoded values and apply the secrets manifest to the Kuma-system namespace:

kubectl apply -f secrets.yaml -n kuma-system

Step 2.4: Add the Kong-Mesh Repo:

Add the Kuma Helm chart repository:

helm repo add kuma https://kumahq.github.io/charts

Step 2.5: Update Chart Values:

Update the values in the values.yaml file to configure the global control plane:

controlPlane:
environment: "universal"
mode: "global"
secrets:
postgresDb:
Secret: your-secret-name
Key: POSTGRES_DB
Env: KUMA_STORE_POSTGRES_DB_NAME
postgresHost:
Secret: your-secret-name
Key: POSTGRES_HOST_RW
Env: KUMA_STORE_POSTGRES_HOST
postgrestUser:
Secret: your-secret-name
Key: POSTGRES_USER
Env: KUMA_STORE_POSTGRES_USER
postgresPassword:
Secret: your-secret-name
Key: POSTGRES_PASSWORD
Env: KUMA_STORE_POSTGRES_PASSWORD

Note: The controlPlane.environment will be "Kubernetes" in a Kubernetes-based deployment, and controlPlane.mode will be "zone" for the zonal control-plane

Step 2.7: Install global control plane

Install the global control plane using Helm:

helm install kuma -f values.yaml - skip-crds -n kuma-system kuma/kuma

Step 2.8: Find the EXTERNAL-IP and Port:

The global control plane's Kuma Discovery Service (KDS) component is responsible for managing the dynamic configuration updates across the entire service mesh. The KDS communicates with each data plane using a secure gRPC-based protocol. KDS is the external IP of the global-zone-sync service and can be accessed as shown below:

kubectl get services -n kuma-system

 NAMESPACE     NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                                                                  AGE
 kuma-system   global-zone-sync     LoadBalancer   10.105.9.10     35.226.196.103   5685:30685/TCP                                                           89s
 kuma-system   kuma-control-plane     ClusterIP      10.105.12.133   <none>           5681/TCP,443/TCP,5676/TCP,5677/TCP,5678/TCP,5679/TCP,5682/TCP,5653/UDP   90s

In this example, the global-kds-address is 35.226.196.103 with port 5685. Note that when the global control plane is on a VM, the public IP of the VM will act as the global-kds-address if you are trying to connect to this control plane from a different network.

Step 3: Set up Zone Control Planes:

We shall install a zonal control plane on a k3s cluster on a different VM. Zone-name is an arbitrary string. This value registers the zone control plane with the global control plane.

helm install kuma \
 - create-namespace \
 - namespace kuma-system \
 - set controlPlane.mode=zone \
 - set controlPlane.zone=<zone-name> \
 - set ingress.enabled=true \
 - set controlPlane.kdsGlobalAddress=grpcs://<global-kds-address>:5685 \
 - set controlPlane.tls.kdsZoneClient.skipVerify=true kuma/kuma

Note that this zonal control plane is already connected to the global control plane as we passed the global kds value to the 'controlPlane. kdsGlobalAddress' variable during installation.

Step 4: Enable Mesh and Deploy a Sample App

One way to enable a mesh for Kubernetes deployments is through labeling a namespace. When you label the namespace with a specific annotation, it instructs Kuma to inject the sidecar proxy into the pods running in that namespace

Step 4.1: Create a Namespace and Enable Sidecar Injection
Create a Kubernetes namespace for your application:

kubectl create ns <name-space> kubectl label ns <name-space> kuma.io/sidecar-injection=enabled

Any deployments in this labeled namespace are part of the mesh.

Step 4.2: Deploy a Sample App
Deploy a sample app in this namespace using a Debian-based Node.js container image:

kubectl create deploy - image debianmaster/nodejs-welcome <deployment-name> -n <name-space>

Step 4.3: Expose the Deployment as a Service

Expose the deployment as a service using a NodePort type:

kubectl expose deployment <deployment-name> - type=NodePort - name=<service-name> - port=8080 - target-port=8080 -n <name-space>

Note: Verify mesh by inspecting the pod containers.
To access Kuma through GUI or kumactl, we need to first port-forward the API service with the following:

kubectl port-forward svc/kuma-control-plane -n kuma-system 5681:5681

You can run kumactl get zones command, or check the list of zones in the web UI for the global control plane to verify zone control plane connections.

Note: If the kumactl is not connected to the global control plane, run the below command to establish a connection

kumactl config control-planes add --name=<name> --address htto://localhost:5681

When a zone control plane connects to the global control plane, the Zone resource is created automatically in the global control plane.

And then navigate to :5681/gui see the GUI.

You will notice that Kuma automatically creates an mesh entity with name. default.

Step 5: Test Cross-Zone Communication

Replicate the above local zone creation steps and create a second zone.

Step 5.1: Patch the ZoneIngress:

For enabling cross-zone communication in the current scenario where the zones are on different networks, the 'advertisedAddress' in the ingress object needs to be the public IP of the VM where the zone is hosted. This can be done by editing the zonengress (edit ingress object of zone1):

$ kubectl -n kuma-system patch zoneingress "$(kubectl -n kuma-system get zoneingress -o=jsonpath='{.items[0].metadata.name}')" --type='json' -p='[{"op": "replace", "path": "/spec/networking/advertisedAddress", "value": "<publicIP-of-VM>"}]'

Step 5.2: Test the cross-zone connection:

Open a shell prompt ('exec -it') inside a pod/deployment of zone1 and try to connect to services in zone2. Get the service addressPort of zone2 using the command below:

kubectl get serviceinsight all-services-default -oyaml   ## (get the addressPort of requried zone 2service)

kubectl exec -it <zone1-workload-pod-name> sh 
curl http://<zone2-service-addressPort>

Note: If curl is not found inside the pod, install it through apk update.

Conclusion:

Congratulations! You have successfully deployed a multi-zone global control plane using Kuma and Kubernetes. With Kuma's powerful service mesh capabilities, you can manage and secure communication between services across multiple zones. Following the steps outlined in this article, you have learned how to set up the global control plane, connect zonal control planes and enable cross-zone communication. Explore further to leverage the full potential of Kuma and enhance the connectivity and security of your distributed applications.

For more information visit: https://zelarsoft.com/

Kong Hybrid Mode Deployment: GKE and On-Prem

Zelar — Tue, 14 May 2024 07:09:12 +0000

Mastering Certificate Challenges with Ease

By Amrutha Paladugu
Author LinkedIn: https://www.linkedin.com/in/amrutha-paladugu/

Introduction:

Kong Hybrid mode represents a groundbreaking approach to API management, merging the control plane (CP) and data plane (DP) capabilities. This mode offers many benefits that empower organizations to achieve enhanced control, security, and performance in their API ecosystem. In this article, we’ll delve into a real-world scenario showcasing the capabilities of Kong Hybrid mode. Specifically, we’ll explore the deployment of Kong Hybrid across Google Kubernetes Engine (GKE) and an On-Premise Kubernetes cluster. We will focus on achieving secure communication, certificate management, workload deployment, and external access. Join us as we navigate this journey through a hybrid API management deployment.

Kong Hybrid architecture with one DP on the cloud and one DP on-premise.

Understanding Certificates:

Mutual Transport Layer Security (mTLS) plays a vital role in Kong’s security features by facilitating secure communication between services. When operating in hybrid mode, the authentication process relies on an mTLS handshake to ensure that communication between CP and DP nodes remains secure, requiring the presentation of certificates. Kong manages certificate key pairs in two distinct modes: Shared and PKI.

In the Shared mode (the default setting), Kong CLI generates a certificate/key pair, and copies of this pair are then distributed across nodes. CP and DP nodes share and utilize this certificate/key pair.

On the other hand, in the PKI mode, certificates signed by a central certificate authority (CA) are provided. Kong performs validation on both ends by verifying if they originate from the same CA. This approach effectively mitigates the risks associated with the transportation of private keys and provides increased security. If one of the DP nodes is compromised, an attacker won’t be able to affect other nodes in the Kong cluster.

In this article, we will use PKI mode and generate three different cert/key pairs for CP and the 2 DPs. All three pairs need to be signed by the same CA discussed above.
Additionally, we will provision a Let’s Encrypt certificate for DP1’s public-facing endpoint and verify encrypted traffic.

Certificate generation:

Step1: Generate CA cert using OpenSSL:

openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt

Step2: Generate private key and CSR(certificate signing request) for CP and DPs

openssl req -new -newkey rsa:2048 -nodes -keyout cp-tls.key -out cp-tls.csr -subj "/CN=*.kong.example.com"
openssl req -new -newkey rsa:2048 -nodes -keyout dp1-tls.key -out dp1-tls.csr -subj "/CN=*.kong.example.com"
openssl req -new -newkey rsa:2048 -nodes -keyout dp2-tls.key -out dp2-tls.csr -subj "/CN=*.127.0.0.1.nip.io"

The CN (Common Name) here would be your wildcard domain.

Step3: Use CA from Step1 to sign the generated CSRs from Step2

openssl x509 -req -in cp-tls.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out cp-tls.crt -days 365
openssl x509 -req -in dp1-tls.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dp1-tls.crt -days 365
openssl x509 -req -in dp2-tls.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dp2-tls.crt -days 365

Step4: Create bundle certs:

cat cp-tls.crt ca.crt > cp-tls-bundle.crt
cat dp1-tls.crt ca.crt > dp1-tls-bundle.crt
cat dp2-tls.crt ca.crt > dp2-tls-bundle.crt

Note: Save these certificates in an accessible directory (certs) for the CP and the DPs.

Install CP and DP1 on GKE:

Connect to a GKE cluster and use the next set of commands to install CP and DP1.

Create ns, Create secrets, update helm repo:

sudo snap install helm - classic
helm repo add kong https://charts.konghq.com
helm repo update
kubectl create namespace kong-cp
kubectl create namespace kong-dp1

Create secrets for Kong Enterprise license, Session Config, Admin password, and Postgresql password:

kubectl create secret generic kong-enterprise-license -n kong-cp \
 - from-file=license=license.json \
 - dry-run=client -o yaml | kubectl apply -f -

kubectl create secret generic kong-session-config -n kong-cp \
 - from-literal=portal_session_conf='{"storage":"kong","secret":"super_secret_salt_string","cookie_name":"portal_session","cookie_samesite":"off","cookie_secure":false, "cookie_domain": ".example.com"}' \
 - from-literal=admin_gui_session_conf='{"cookie_name":"admin_session","cookie_samesite":"off","secret":"super_secret_salt_string","cookie_secure":false,"storage":"kong", "cookie_domain": ".example.com"}'

kubectl create secret generic kong-manager-password -n kong-cp \
 - from-literal=password=password

kubectl create secret generic kong-cp-postgresql -n kong-cp \
 - from-literal=host="enterprise-postgresql.kong.svc.cluster.local" \
 - from-literal=password=password

Note: If you don’t have access to an Enterprise license, you can still go ahead and try the installation but will not be able to access the Admin GUI.

Now, create Kubernetes Secrets for the cluster cert and CA cert for ns kong-cp.

kubectl create secret tls kong-cluster-cert -n kong-cp \
 - cert=./certs/cp-tls-bundle.crt \
 - key=./certs/cp-tls.key

kubectl create secret generic kong-ca-cert -n kong-cp \
 - from-file=ca.crt=./certs/ca.crt

We use Helm to install the CP and DPs and use custom values.yaml files.

Update the values-cp.yaml with the below values:

image:
  repository: kong/kong-gateway
  tag: "3.4"

secretVolumes:
  - kong-cluster-cert
  - kong-ca-cert

env:
  role: control_plane
  cluster_mtls: pki
  cluster_ca_cert: /etc/secrets/kong-ca-cert/ca.crt
  cluster_cert: /etc/secrets/kong-cluster-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  nginx_http_ssl_protocols: TLSv1.2
  admin_gui_ssl_cert: /etc/secrets/kong-cluster-cert/tls.crt
  admin_gui_ssl_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  admin_ssl_cert: /etc/secrets/kong-cluster-cert/tls.crt
  admin_ssl_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  portal_gui_ssl_cert: /etc/secrets/kong-cluster-cert/tls.crt
  portal_gui_ssl_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  portal_api_ssl_cert: /etc/secrets/kong-cluster-cert/tls.crt
  portal_api_ssl_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  lua_ssl_verify_depth: 3
  admin_api_uri: https://admin.kong.example.com
  admin_gui_url: https://manager.kong.example.com
  portal_auth: basic-auth
  portal_api_url: https://portal-api.kong.example.com
  portal_gui_url: https://portal-dev.kong.example.com
  portal_gui_host: portal-dev.kong.example.com
  portal_gui_protocol: https
  database: postgres
  pg_host: kong-cp-postgresql
  pg_database: kong
  pg_user: postgres
  pg_schema: kong
  pg_password:
    valueFrom:
      secretKeyRef:
        name: kong-cp-postgresql
        key: password
  portal_session_conf:
    valueFrom:
      secretKeyRef:
        name: kong-session-config
        key: portal_session_conf
  user: kong
  password:
    valueFrom:
      secretKeyRef:
        name: kong-manager-password
        key: password

admin:
  enabled: true
  type: ClusterIP
  annotations:
    konghq.com/protocol: https
  labels: {}
  http:
    enabled: false
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8444
    parameters:
      - http2
  ingress:
    annotations:
      konghq.com/https-redirect-status-code: "301"
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    enabled: true
    ingressClassName: kong-dev
    hostname: admin.kong.example.com
    path: /
    tls: kong-cluster-cert

manager:
  enabled: true
  type: ClusterIP
  annotations:
    konghq.com/protocol: https
  labels: {}
  http:
    enabled: false
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8445
    parameters:
      - http2
  ingress:
    annotations:
      konghq.com/https-redirect-status-code: "301"
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    enabled: true
    ingressClassName: kong-dev
    hostname: manager.kong.example.com
    path: /
    tls: kong-cluster-cert

cluster:
  enabled: true
  type: LoadBalancer
  annotations: {}
  http:
    enabled: false
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8005
  ingress:
    annotations:
      konghq.com/https-redirect-status-code: "301"
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    enabled: true
    ingressClassName: kong-dev
    hostname: cp.kong.example.com
    path: /
    tls: kong-cluster-cert

clustertelemetry:
  enabled: true
  type: LoadBalancer
  http:
    enabled: false
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8006
  ingress:
    annotations:
      konghq.com/https-redirect-status-code: "301"
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    enabled: true
    ingressClassName: kong-dev
    hostname: tel.kong.example.com
    path: /
    tls: kong-cluster-cert

proxy:
  enabled: false

ingressController:
  enabled: true
  ingressClass: kong-dev
  resources:
    limits:
      cpu: 200m
      memory: 256Mi
    requests:
      cpu: 100m
      memory: 128Mi
  installCRDs: false
  env:
    publish_service: kong-dp/kong-dp-kong-proxy
    kong_admin_token:
      valueFrom:
        secretKeyRef:
          name: kong-manager-password
          key: password

enterprise:
  enabled: true
  license_secret: kong-enterprise-license # CHANGEME
  vitals:
    enabled: false
  rbac:
    enabled: true
    session_conf_secret: kong-session-config
    admin_api_auth: basic-auth
  portal:
    enabled: true
  smtp:
    enabled: false

portal:
  enabled: true
  type: ClusterIP
  annotations: 
    konghq.com/protocol: https
  labels: {}
  http:
    enabled: false
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8446
  ingress:
    annotations:
      konghq.com/https-redirect-status-code: "301"
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    enabled: true
    ingressClassName: kong-dev
    hostname: portal-dev.kong.example.com
    path: /
    tls: kong-cluster-cert

portalapi:
  enabled: true
  type: ClusterIP
  annotations: 
    konghq.com/protocol: https
  labels: {}
  http:
    enabled: false
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8447
  ingress:
    annotations:
      konghq.com/https-redirect-status-code: "301"
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    enabled: true
    ingressClassName: kong-dev
    hostname: portal-api.kong.example.com
    path: /
    tls: kong-cluster-cert

postgresql:
  enabled: true
  auth:
    database: kong
    username: postgres
    existingSecret: kong-cp-postgresql
    secretKeys:
      adminPasswordKey: password

Let’s try and understand the above values file:

The secrets we created, kong-cluster-cert and kong-ca-cert are mounted as volumes for the SSL certificates and are accessed at the specified path, for example:

cluster_ca_cert: /etc/secrets/kong-ca-cert/ca.crt

The environment variables are for configuring Kong and its components. They control settings related to SSL/TLS, database connections, authentication, and more. Also, they specify the role as “control_plane” and enable cluster mutual TLS (mTLS) using the PKI method. The admin API and GUI URLs, authentication methods, and other configuration parameters are also defined using the env variables.

Admin, Manager, Portal, Portal API, and PostgreSQL:

These sections configure various components of Kong. All these components are enabled for the CP and would be disabled in the DP values yaml. Their type ( ClusterIP), TLS, and Ingress settings are also defined, including annotations, hostnames, paths, and TLS certificates for these components.
PostgreSQL settings specify authentication details for connecting to the PostgreSQL database used by Kong.
Enterprise-related settings include the license secret, RBAC configuration, SMTP, and vitals.

Proxy and Ingress Controller:

The proxy section specifies whether the Kong proxy is enabled. For CP values, this would be disabled as the DP does all the proxying.
Ingress Controller settings define the resources and environment variables for the Kong Ingress Controller.

Cluster and Cluster Telemetry:

Cluster and cluster telemetry are essential for Kong Gateway’s Control Plane (CP) and Data Plane (DP) connection. DP instances connect to the CP through the CP cluster, which provides redundancy, load balancing, and configuration synchronization.
Cluster telemetry plays a crucial role in monitoring the health of both CP and DP components, ensuring they can work together effectively and respond to changes and issues in real time. This setup provides a reliable and resilient CP-DP connection in Kong Gateway deployments.

Install the CP:

helm upgrade - install kong-cp kong/kong - namespace kong-cp -f values-cp.yaml

Once the CP is installed, verify that all pods are running and the Cluster and Clusterterlemetry services’ external LoadBalancer IPs are ready.

To install DP in the same cluster, follow the steps below and create license and certificate secrets for DP1.

kubectl create secret generic kong-enterprise-license -n kong-dp1 \
  --from-file=license=license.json \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl create secret tls kong-cluster-cert -n kong-dp1 \
 - cert=./certs/dp1-tls-bundle.crt \
 - key=./certs/dp1-tls.key

kubectl create secret generic kong-ca-cert -n kong-dp1 \
 - from-file=ca.crt=./certs/ca.crt

To encrypt the oneway traffic to the public-facing end point of DP1, we use Let’s Encrypt CA. Use the below link to generate one for the domain you use.

SSL Certificate Generator: Free letsencrypt SSL in minutes:

A free SSL Certificate Generator. No login is required. Secure your site with a letsencrypt certificate. Includes a…
punchsalad.com

Create a secret for this cert in the kong-dp1 namespace:

kubectl create secret tls kong-tls-cert -n kong-dp1 \
 - cert=./letsencrypt/ca.crt \
 - key=./letsencrypt/ca.key
Create a values-dp1.yaml file with the below values:
image:
  repository: kong/kong-gateway
  tag: "3.4"

secretVolumes:
  - kong-cluster-cert
  - kong-ca-cert
  - kong-tls-cert

env:
  role: data_plane
  database: "off"
  status_listen: 0.0.0.0:8100
  cluster_control_plane: cp.kong.example.com:443
  cluster_telemetry_endpoint: tel.kong.example.com:443
  cluster_mtls: pki
  cluster_server_name: cp.kong.example.com
  cluster_telemetry_server_name: tel.kong.example.com
  lua_ssl_verify_depth: 3
  cluster_ca_cert: /etc/secrets/kong-ca-cert/ca.crt
  lua_ssl_trusted_certificate: /etc/secrets/kong-cluster-cert/tls.crt
  cluster_cert: /etc/secrets/kong-cluster-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  ssl_cert: /etc/secrets/kong-tls-cert/tls.crt
  ssl_cert_key: /etc/secrets/kong-tls-cert/tls.key

ingressController:
  enabled: false

enterprise:
  enabled: true
  license_secret: kong-enterprise-license
  vitals:
    enabled: false
  portal:
    enabled: false
  rbac:
    enabled: false

admin:
  enabled: false

manager:
  enabled: false

portal:
  enabled: false

portalapi:
  enabled: false

proxy:
  enabled: true
  type: LoadBalancer
  annotations: {}
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8443
    parameters:
      - http2
  # stream: {}
  ingress:
    enabled: true

Please take note of the key differences here from the earlier values-cp yaml. All the Manager, Admin, Portal, Portalapi, and IngressController sections are disabled, while the Proxy section is enabled as type LoadBalancer. As explained earlier, ensuring the correct configuration of cluster and cluster telemetry endpoints is crucial.

Another point worth mentioning is the secret volume for the Let’s Encrypt certificate:kong-tls-cert. This is accessed through the below variables:

ssl_cert: /etc/secrets/kong-tls-cert/tls.crt ssl_cert_key: /etc/secrets/kong-tls-cert/tls.key

Install DP1:

helm upgrade --install kong-dp1 kong/kong --namespace kong-dp1 -f values-dp1.yaml

Note the LoadBalancer IPs for the Cluster and Clustertelemetry service in the CP and the Proxy service in the DP. Map these values to the domain you intend to use. In our scenario, it would be as follows:

cp.kong.example.com - - - - - - - > 34.136.32.39

cp-tel.kong.example.com - - - - >34.68.58.255

*.kong.example.com - - - - - - - - >34.132.64.159

You should now be able to access Kong Manager (in case you are using an Enterprise license) at manager.kong.example.com, but the browser won’t recognize the OpenSSL CA, and hence it will appear as NotSecure as shown in the below image.

Access Admi GUI and view certificate (Not Secure- openSSL)

Deploy a sample application:

Let’s deploy a sample nodeJS application in the same GKE cluster in the default namespace, try accessing it through the DP endpoint, and see if the Let’s Encrypt certificate is served.

kubectl create deploy --image debianmaster/nodejs-welcome welcome 
kubectl expose deployment welcome --type=LoadBalancer --name=welcome --port=8080 --target-port=8080

Deploying a sample nodeJS ‘welcome’ application

Add a service and a route to this application through the Kong manager.

Now, the workload can be accessed through dp1.kong.example.com/welcome. Click on the lock icon🔒present right before the URL and view the certificate. You will notice that the Let’s Encrypt certificate is being served, as shown in the below image.

Access the workload through the DP endpoint and verify the Let’s Encrypt cert.

Install DP2 on local K3s:\

Connect to a local K3s (lightweight Kubernetes) cluster and install the following command set to install DP2.
Create namespace for DP2

kubectl create ns kong-dp2

Create secrets for enterprise licenses and certificates:

kubectl create secret generic kong-enterprise-license - from-file=license=./license.json -n kong-dp2 - dry-run=client -o yaml | kubectl apply -f -

kubectl create secret tls kong-cluster-cert -n kong-dp2 \
 - cert=./certs/dp2-tls-bundle.crt \
 - key=./certs/dp2-tls.key

kubectl create secret generic kong-ca-cert -n kong-dp2 \
 - from-file=ca.crt=./certs/ca.crt

Create a values-dp2.yaml file with the below values:

image:
  repository: kong/kong-gateway
  tag: "3.4"

secretVolumes:
  - kong-cluster-cert
  - kong-ca-cert

env:
  role: data_plane
  cluster_control_plane: cp.kong.example.com:443
  cluster_telemetry_endpoint: tel.kong.example.com:443
  lua_ssl_trusted_certificate: /etc/secrets/kong-cluster-cert/tls.crt
  cluster_mtls: pki
  cluster_server_name: cp.kong.example.com
  cluster_telemetry_server_name: tel.kong.example.com
  cluster_ca_cert: /etc/secrets/kong-ca-cert/ca.crt
  cluster_cert: /etc/secrets/kong-cluster-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-cert/tls.key
  database: "off"
  audit_log: "on"
  headers: "off" 
  anonymous_reports: "off"
  untrusted_lua: "off"

enterprise:
  enabled: true
  license_secret: kong-enterprise-license
  vitals:
    enabled: false
  portal:
    enabled: false
  rbac:
    enabled: false
admin:
  enabled: false
manager:
  enabled: false
portal:
  enabled: false
portalapi:
  enabled: false
ingressController:
  enabled: false

proxy:
  enabled: true
  type: LoadBalancer
  annotations: {
    konghq.com/protocol: "https"
  }
  tls:
    enabled: true
    servicePort: 443
    containerPort: 8443
    parameters:
    - http2
  ingress:
    enabled: true
Install DP2
helm upgrade - install kong-dp2 kong/kong - namespace kong-dp2 -f values-dp2.yaml

Deploy a sample application in the K3s cluster:

Let’s deploy a sample nodeJS application in the same K3s cluster in the default namespace and try to access it through the DP2 endpoint and verify.

kubectl create deploy --image debianmaster/nodejs-welcome hello 
kubectl expose deployment hello --type=LoadBalancer --name=hello --port=8080 --target-port=8080

Verify deployment of nodeJS ‘hello’ application.

Add a service and a route to this application through the Kong manager.

Now the workload can be accessed through dp2.127.0.0.1.nip.io/hello

Conclusion:

Throughout this article, we embarked on a journey to uncover the transformative power of Kong Hybrid mode within API management. By harmonizing the control plane (CP) and data plane (DP), Kong Hybrid empowers organizations to balance control, security, and performance seamlessly. Through a real-world scenario, we showcased the deployment of Kong Hybrid across Google Kubernetes Engine (GKE) and an On-Premise Kubernetes cluster.

We navigated the intricate landscape of certificate management, emphasizing the pivotal role of Mutual Transport Layer Security (mTLS) and certificates in fortifying Kong’s security architecture. By embracing PKI mode, we ensured secure communication and mitigated the risks inherent in key transportation.

By following our straightforward, step-by-step instructions, we achieved successful deployments of Kong CP and DP1 within the GKE cluster, followed by Kong DP2 in an On-Premise K3s cluster. We highlighted the deployment of sample applications, demonstrated access through DP endpoints, and verified Let’s Encrypt certificates, reinforcing the foundation of a robust and secure API ecosystem.

As we wrap up this journey, remember the importance of resource cleanup to prevent lingering costs. The world of Kong Hybrid mode introduces a revolutionary approach that bridges the gap between Cloud and On-Premise, enabling the creation of APIs that transcend traditional confines. With mastery of this approach, you’ll confidently and innovatively navigate the dynamic realm of modern API management.

For more details visit: [https://zelarsoft.com/kong-consulting-and-licensing/]

Streamlining Microservices Orchestration: A Guide to Deploying Kong-Mesh Zones with Konnect

Zelar — Thu, 02 May 2024 07:32:38 +0000

By Amrutha Paladugu
Author LinkedIn: https://www.linkedin.com/in/amrutha-paladugu/

Introduction:

In this blog post, we will explore the deployment of Kong-Mesh zones using Kong’s Konnect platform. Kong-Mesh provides a powerful service mesh solution for managing and orchestrating microservices. By leveraging Konnect, users can easily set up and configure global control planes, connect zones, and deploy applications within the mesh.

To get started, sign up for a free account at https://cloud.konghq.com/ and receive $500 worth of free credits. After logging in, navigate to the Mesh Manager in the Konnect UI, where you can manage global control planes for Kong-Mesh. Figure 1 shows the screenshot of Mesh Manager which already has one global control plane meshcp

Figure 1: Mesh Manager on Konnect UI

Creating Global Control Plane:

Begin by creating a new global control plane in the Mesh Manager. Specify a name and optional label, then save the configuration. This control plane will serve as the central hub for managing and controlling your mesh.

Installing Kumactl:

For this blog, we are deploying everything on a local K3s cluster but Kong-Mesh zones can be deployed onto any non-kubernetes environment as well. To interact with the Kong-Mesh from your local machine, install kumactl. Follow the provided shell commands to install and verify the version. This step ensures that you can configure kumactl to work with your Kong-Mesh deployment.

curl -L https://docs.konghq.com/mesh/installer.sh | VERSION=2.6.1 sh - cd kong-mesh-2.6.1/bin export PATH=$(pwd):$PATH cd ../..

Verify the installation using the below command:

kumactl version

The output would be something like in Figure 2.

Figure 2: Checking the kumactl version installed

Configuring Kumactl with Konnect:

In the Konnect UI Mesh Manager, go to your global control plane, click on Global Control Plane Actions, and further configure kumactl. This involves creating a Konnect Personal Access Token (PAT) and following the provided steps (refer to figures 3 & 4). Once configured, kumactl will be set up on your local machine.

Figure 3.1: Demonstration of configuring kumactl

Figure 3.2: Steps to configure kumactl

Figure 4: Creating a PAT

Use this PAT and run the next steps to complete the kumactl configuration. Once it is done, you will see the output as shown in Figure 5.

Figure 5: kumactl configured in your local k3s cluster.

Creating and Connecting Zones:

Proceed to create a zone within the Mesh Manager. Within your global cp, click on the Create Zone button, and name it appropriately. Follow the steps (presented to you on the UI) to generate a token and install the mesh with the presented values. Upon successful completion, the zone will be created and online, ready for use. Refer to figures 6, 7 & 8.

Figure 6: Create Zone

Figure 7: Create and connect the Zone.

Figure 8: Zone is created and is online.

Deploying a Sample Application:

To showcase Kong-Mesh in action, deploy a sample hello-world application within the mesh. The provided Kubernetes deployment and service YAML files include creating a new namespace and enabling sidecar injection. (Note: You may choose to deploy any other app in place of the nodjes image I used in this yaml). Apply these configurations using kubectl, and verify the successful deployment in the Konnect UI Mesh Manager.

`apiVersion: v1 kind: Namespace metadata: name: hello-world labels: kuma.io/sidecar-injection: enabled---
apiVersion: apps/v1 kind: Deployment metadata: name: hello-world namespace: hello-world spec: replicas: 1 selector: matchLabels: app: hello-world template: metadata: labels: app: hello-world spec: containers: - name: hello-world image: pamrutha88/hello-world-nodejs:latest #use a choice of your app image in-place of this image ports: - containerPort: 8080---
apiVersion: v1 kind: Service metadata: name: hello-world namespace: hello-world spec: selector: app: hello-world ports: - protocol: TCP port: 80 targetPort: 8080

Save and apply this yaml using the below command:

kubectl apply -f hello-world.yaml

Once the deployment is complete, verify that the pods are running and once that’s done, we can view this service in the Konnect UI Mesh Manager as shown in Figure 9.

Figure 9: Example deployed service within the zone.

If you click on the Data Plane Proxies, you can observe that under Certificate Info there is no certificate issued yet. This is because we have not enabled mTLS on this mesh which can be done using the below yaml.

name: default type: Mesh mtls: enabledBackend: ca-1 backends: name: ca-1 type: builtin networking: outbound: passthrough: true

Save this into mesh.yaml file and apply using the below command:

kumactl apply -f mesh.yaml

You can see that the changes are reflected in the Konnect immediately, refer to Figure 10.

Figure 10: Built-in certificates issued by Kong-Mesh

Conclusion:

With Kong-Mesh and Konnect, deploying and managing service meshes becomes a streamlined process. The integration of global control planes, zones, and kumactl configuration provides a comprehensive solution for orchestrating microservices in a scalable and efficient manner. Explore the capabilities of Kong-Mesh through Konnect and witness the seamless deployment of applications within the mesh.

For more details visit: [https://zelarsoft.com/kong-consulting-and-licensing/]