For the past week, I had the chance to explore a tool called Insomnia by Kong and thought I'd share my learnings through this blog. So here we go.

Imagine you're a developer, sitting at your desk late at night, surrounded by coffee cups and lines of code. You've been tasked with integrating a new API, but every time you test it, something goes wrong. The errors are vague, the debugging process is tedious, and you start feeling that familiar frustration creep in - you wonder, Isn’t there an easier way to do this?💭

Enter Insomnia – but don’t let the name fool you! This isn’t the kind of insomnia that keeps you awake at night; in fact, it’s here to save you from sleepless nights. 🤪

You quickly realize that Insomnia isn't just another API client – it’s a one-stop shop. You can Design, Debug, and Test APIs all in one go.

No more jumping between different tools to authenticate, debug, and test your requests. With Insomnia’s built-in authentication helpers, you can set up OAuth, Basic Auth, or any token-based security in just a few clicks.

You can set up environment variables for different stages – from development to production – keeping your workspace organized and neat. No more fumbling around changing URLs manually.

But wait, there’s more: your API isn't live yet, and you need to simulate responses. Not a problem! You use Insomnia to mock APIs and simulate server behaviour, allowing you to test without ever having to spin up a backend. With the real-time collaboration feature, your entire team can jump in, test, and debug right alongside you.

As you watch your API deliver a smooth "200 OK" ✅ and your tests succeed one after another, you feel a sense of relief and accomplishment. Insomnia isn’t just a tool, it’s your secret weapon against the chaos of API development.

And there's even more! Here are the storage options you can use for your projects, collections, specs, and other files:

• Local Vault: Store your collections, design specs, and other resources locally.

• Cloud Sync: Collaborate in the cloud with end-to-end encryption (E2EE) for free.

• Git Sync: Use any third-party Git repository to store all your files.

So, how do you get started?

Getting started is easy! Insomnia is available for Mac, Windows, and Linux, so no matter what platform you’re on, you’re covered. You can download it from their website: https://insomnia.rest/download

We'll be trying Insomnia together 🌱

Now, let's send our first request! 🎊

Make a new collection by clicking the + icon in the sub-menu named Collections and name it Demo.

You'll see something like this. Now, let's create a new HTTP request. I've already made an API you can use to test it out :D (but feel free to use any API you like! 😉)

Here's the Github repo

I've made a basic API that handles signup and login. Here's how it works:

1. [GET] Request to check if the server is running or not.

2. [POST] Sign up a new user with a username and password.

3. [POST] Log in with the same credentials, and you'll get an access token. This means the user is authenticated.

4. [GET] Use the access token to access the protected route.

📌 Click on New HTTP Request

Let's try the GET request and check out the preview. Use this API path: https://insomnia-demo.vercel.app/ and hit SEND. This is the API which I developed

Note: It's an open route.

This means that anyone with the URL of the API can send requests to it and receive a response, without needing credentials like an API key, token, or login.

YAY 🎉, the server is up and running!

What else do we see? 👀

1. Status 200 OK: Right away, you can see if your request worked.

2. Execution Time: Check how long your request took – super handy for performance insights.

3. Headers: Get a detailed look at request and response headers, which is great for debugging and understanding how the API works.

4. Response Size: See the size of the response, whether it’s 24B or 24MB – every byte counts!

5. Mock Servers: No real server to test with? No worries. You can mock API responses and simulate server behavior for testing.

6. Cookies: Keep an eye on cookies (if any) that get sent or received during the request, making session management a breeze.

Let's test the other APIs that we mentioned before and see if they work.

Create a new request. For the quick tutorial, we'll be doing HTTP requests, but you have so many options. You can also organize your interface using folders to keep your APIs tidy📂

We'll be signing up the user now. Use this API path https://insomnia-demo.vercel.app/signup

Okay, so I made this POST request. Did you notice something? The domain https://insomnia-demo.vercel.app is used everywhere.

You can set up environment variables to reuse values across multiple requests. Common examples include base URLs, authentication tokens, and resource IDs. This approach helps keep your requests organized and avoids repetitive configuration, making your API testing more efficient. Let's set one up.

Head over to the Base Environment option and click the pencil ✏️

Put this in the body for our tutorial
Note: the variable name can be anything as you would like

     {
       "host": "insomnia-demo.vercel.app"
     }

And that's it, you're done 👍

Add the BODY. There are a ton of options to choose from, but I'm going with JSON.

{
    "username": "Joey",
    "password": "danse123"
}

User is registered successfully ✅

Now let's Log in the user. Use this API Path: https://insomnia-demo.vercel.app/login

Use the same login credentials which you did for Sign up. YAY, we got the access token!

Here are the header details

📌 Final step, let's access the protected route and see if it works.

A protected route in an API is an endpoint that requires authentication and/or authorization to access.

Use this API Path: https://insomnia-demo.vercel.app/protected

We have a few Auth options, but for this example, we're going with the Bearer token.

Voila! Using the access token, we got access to the protected route!

Now, let's check out some quick scenarios we forgot to test 🧪

📌 Scenario 1: What if the route path isn't correct?

📌 Scenario 2: What if the password is wrong?

📌 Scenario 3: What if we try to log in but the user doesn't exist?

📌 Scenario 4: What if the access token has expired or is wrong?

All the scenarios work just like we expected, and the preview tool gives the right status codes! It was super easy and user-friendly to use.

Oh, and there's another awesome feature I want to mention: Import/Export 👾

From the Document or Collection name dropdown menu, select Import/Export.

Here's the complete YAML file of the environment we set up in Insomnia.

Also, if you want to work with others in the environment, you can just invite them.

Which will look something like this. Pretty cool, right?

And there you have it, we explored Insomnia together 🦸🏻‍♀️

If you haven’t tried Insomnia yet, now’s the perfect time to see how it can boost your development experience. Download it, check out its features, and see how it changes your approach to API testing.

Got questions or stories to share? Drop them in the comments below – I’d love to hear how Insomnia is working for you. 😍

I'll be back with more tutorials on Insomnia, so stay tuned and see you in the next one.

Also, check out our Twitter/X spaces that we host weekly!! 😉

Wait.. have you heard about the Kong API Summit?

The API Summit by Kong unites top minds in the API space to share best practices for building, running and governing APIs across any environment. Learn how to achieve zero-trust security, enhance developer productivity, reduce operational overhead and maximise ROI.

Sign up for the Kong API Summit, which will be held virtually from 11-12 September! And attend talks & keynotes from some amazing speakers onboard! 😍

What is Procurement 🤔

In tech, I need to buy something from a vendor. I either can work with a reseller who aggregates multiple vendors for me, or work directly with a vendor. Both have their advantages and disadvantages but it comes down to cost, speed, interoperability and support.

If a Dev needed a server, I'd call up one of my contacts and I'd request a quote that comprised of:

• The server itself (rack or tower)

• A specification for CPU and memory

• Disk configuration, RAID cards (and maybe some SAN-related network cards)

• Cables

If approved, I'd place the order and the gear would arrive in 2 weeks. TWO WEEKS. WHAT SPEED. Seriously, procurement times would vary and a lot of this would be tied to logistics, availability, and delivery. Once it all arrived, I still needed time to rack, and configure the server install an OS, patch it, add it to the network, join a domain, and do some final checks/tests for readiness. Once all was good, that Dev got access. Until they needed another server.

Kubernetes Namespaces 🪄

Within the development world, you have multiple different teams such as developers, QA testers, and many more. Each of these teams requires a dedicated environment to carry out their work. Provisioning them with dedicated clusters can become very expensive and is, therefore, not an ideal solution. Instead, why not provide them with dedicated namespaces within the same Kubernetes cluster? You can spin up a namespace very easily and provision it to the individual teams. However, if you had to manually create all the appropriate authorization mechanisms and isolation boundaries for policies, that would involve a lot of manual work. This is where OpenUnison shines.

Splitting the cluster among all these different teams using namespaces is also what we call Multi-Tenancy. Multi-Tenancy in the simplest terms can be understood as “single resource, multiple users”.

When Kubernetes started gaining traction about a decade ago, multi-tenancy wasn’t a common discussion point. However, during the first KubeCon in 2016, OpenUnison showcased a multi-tenant Kubernetes stack, highlighting the potential and importance of this feature.

Benefits of Multi-Tenancy

1. Cost Efficiency: Multi-tenancy reduces the number of control planes, cutting costs associated with hardware, management, and auditing.

2. Human Resource Management: Kubernetes expertise is expensive and in high demand. Multi-tenancy minimizes the need for a Kubernetes expert in every team, reducing human resource costs.

3. Operational Efficiency: Instead of upgrading numerous clusters and versions, multi-tenancy allows for a single upgrade process, significantly reducing the workload.

4. Self-Service Model: App owners gain control over their environments, while cluster owners are freed from managing individual app owner requests.

To enable our cluster to be multi-tenant, we use a concept called NameSpaces as a Service (NaaS). It essentially manages the entire lifecycle of provisioning the namespace, setting the correct security boundaries, and allowing the developers and other teams to access only their specific namespace.

Tremolo NaaS🔓

Namespace as a Service (NaaS) simplifies the creation and management of Kubernetes namespaces while integrating with identity providers to enforce roles and permissions.

Out of the box, NaaS provides two primary roles: admin and view.

1. Admin View: grants comprehensive control over the namespace, excluding changes to cluster-wide objects like resource quotas

2. View role: Offers read-only access to resources within the namespaces

Additional roles can be customized to meet specific needs, such as granting support staff the ability to delete pods within the Kubernetes dashboard.

How do you manage access groups within a Kubernetes namespace after its creation and association with identity provider groups, ensuring that the cluster admin is not responsible for overseeing access permissions?

To address this, OpenUnison established an approval group, with the requester as the initial member. This setup not only provides a self-service interface for namespace creation but also for managing access.

There are three models for managing access groups:

1. Internal Self-Service Groups: In this model, the cluster owner controls the groups and authorization. While this offers control, it also requires implementing audit policies and reporting, all of which are provided out of the box.

2. External Groups: This model integrates directly with external systems like Okta, Active Directory, or GitHub. It allows for seamless namespace management driven by your corporate identity system, eliminating the need for manual access approvals. The downside is that management relies entirely on the corporate identity system.

3. Hybrid Group: This model leverages the ease of onboarding from external systems while allowing quick internal access adjustments. Most customers start with internal management, switch to external, and eventually adopt the hybrid model for the best of both worlds.

All these processes can be fully automated, ensuring no manual intervention is needed for creating namespaces or managing access.

Implementing NaaS within OpenUnison 🫣

In our upcoming demonstration, we'll showcase the process of requesting a new namespace. Enterprise customers often require additional features, such as chargeback information, which can be easily integrated into the namespace request form.

OpenUnison supports various integrations, enabling the use of tools like Backstage or ServiceNow for interface interactions, instead of the default portal. This flexibility is a key advantage of our approach to multi-tenancy, which balances imperative and declarative methodologies.

Additionally, the system allows writing objects directly to the API or a Git repository, enhancing the flexibility of the namespace creation process.

We can create a Kubernetes object with two flexible approaches;

1. Directly writing to the API Server

2. Using GitOps for version control

To accommodate both methods, OpenUnison includes tools for each. When writing directly to the API server, the process is immediate and simple. However, if you prefer GitOps, you can set the "Write to request" option to true, enabling the accumulation of objects into a buffer during the workflow. Once complete, these objects are pushed to a Git repository using an SSH key.

To ensure seamless integration, we provide a task to wait for the GitOps controller to kick in, maintaining workflow continuity. This dual approach allows you to start with direct API interactions and transition to GitOps when ready, using the same workflows.

NOW come the configs and fun part!!! 😍

Namespace as a Service (NaaS) requires two key components for effective operation.

1. A relational database: It is essential for storing authorization information, synchronizing external identity information into buffer groups for RBAC binding, maintaining audit data, and managing state for asynchronous processes.

2. An SMTP service: It is necessary for sending notifications to relevant stakeholders when access requests are made. While we support SMTP out-of-the-box, enterprises often prefer email notifications despite the rise of platforms like Slack and Teams.

For ease of setup, we provide a MariaDB database for simple deployment and an SMTP Black Hole for handling email notifications without forwarding them, preventing log errors.

You can install the above components by following the Open Unison Documentation.

Deploying The NaaS Portal 🚀

Testing MariaDB

If you need a simple database implementation for testing:

<https://raw.githubusercontent.com/OpenUnison/kubeconeu/main/src/main/yaml/mariadb_k8s.yaml>

If you use this database, use the following configuration information.

Testing SMTP Server

If you don't have an SMTP server available, you can use the SMTP Blackhole to have a place to send email without forwarding it to any recipients:

kubectl create ns blackhole
kubectl create deployment blackhole --image=tremolosecurity/smtp-blackhole -n blackhole
kubectl expose deployment/blackhole --type=ClusterIP --port 1025 --target-port=1025 -n blackhole

If you use the blackhole smtp service, use the following configuration information:

Next, update your values.yaml, uncommenting the database and smtp sections of your values.yaml. As an example, the below will work with the testing database and SMTP server:

database:
  hibernate_dialect: org.hibernate.dialect.MariaDBDialect
  quartz_dialect: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
  driver: org.mariadb.jdbc.Driver
  url: jdbc:mariadb://mariadb.mariadb.svc.cluster.local:3306/unison
  user: unison
  validation: SELECT 1

smtp:
  host: blackhole.blackhole.svc.cluster.local
  port: 1025
  user: "none"
  from: donotreply@domain.com
  tls: false

For enterprises, the system supports Kerberos authentication with SQL Server, allowing you to mount a Kerberos keytab into the namespace for authentication instead of using a password, highlighting the enterprise-level support provided.

With your configuration updated, the next step is to choose which management model to use. We'll be doing the internal groups model.

To deploy the local management self-service model, first enable internal groups by adding the following to your values.yaml:

openunison:
  non_secret_data:
    SHOW_PORTAL_ORGS: "true"
  role_attribute: portalGroups
  groups:
    areJson: "true"
  enable_provisioning: true
  use_standard_jit_workflow: false
  naas:
    groups:
      internal:
        enabled: true

We provide instructions for customizing OpenUnison's configuration, specifically focusing on the role_attribute setting. He suggests changing the attribute name from groups to portalGroups

Explanation

• The role_attribute configuration dictates how OpenUnison processes and displays role-related information.

• By changing this attribute, you're customizing how OpenUnison presents group information. Instead of showing raw group data, it will present a more refined view, displaying permissions and roles in the context of namespaces and clusters.

• This customization helps in better managing and displaying user permissions within the web interface, making it clearer which permissions apply to which namespaces and clusters.

  

We made some additional configurations which are:

1. ChangeareJson to true: This enables the JSON format for groups or roles, ensuring that data is processed or displayed in JSON format.

2. Setenable_provisioning to true: This activates the provisioning feature, allowing for the automated setup of resources or user accounts within OpenUnison.

   

   We also do the following:

   1. Addactive_mq_pvc: true: This line should be added to enable the use of a Persistent Volume Claim (PVC) for ActiveMQ’s data store, in addition to the existing setting for enable_activemq. This change is intended to address issues related to disk space and log management that arose from using a database for ActiveMQ’s data store.

   2. Explanation: ActiveMQ can operate in two modes for its data storage: using a database or a PVC. Initially, a database was used due to local deployment constraints, but this approach caused excessive log growth and potential disk space issues. Switching to a PVC helps mitigate these problems by providing more manageable and scalable storage.

Before deploying using ouctl, ensure that you have a password file for both MariaDB and your SMTP server.

Now we are ready to DEPLOY!!!! 😍

helm repo update

There are a few points to keep in mind. If you run into errors, these will be useful for debugging.

1. PVC Creation: The Persistent Volume Claim (PVC) is created from a StatefulSet template. If the PVC is missing, scale the StatefulSet down to zero and then back up to one to recreate the PVC.

2. Scaling StatefulSet: Ensure that only one replica is running to avoid complications. Multiple replicas can cause issues with PVCs and deployment stability.

3. Check Quota: Verify that you have enough available volume space and that you haven’t exceeded your quota. If necessary, provision additional quota.

4. Re-run ouctl: Once everything is set up correctly and quotas are verified, rerun the ouctl command to continue with the deployment process.

An additional deployment for ActiveMQ is set up and running, functioning as a message bus. The version currently deployed is not High Availability (HA) and is intended primarily for initial setup and testing. It is not suitable for production environments.

Now go ahead and log into your OpenUnison!

An option there called local deployment so that's where your tokens and your dashboard

Now go click on your account information in the upper left-hand corner

As the first person setting up the system, you automatically become the administrator. This is because it's common practice to grant administrative rights to the person who initiates the setup process. The system is designed to automate this assignment, ensuring that the initial setup user has the appropriate administrative access from the start.

Now let's create k8s namespace!

Click on “New Kubernetes Namespace”

You can give your namespace a unique name and create the namespace.

Now comes the Open Approvals & Reports section.

Under the "Reports" section, locate the "Users" button and search for your name.

Use the "Add to Cart" feature to manage workflows for this user, such as assigning roles or running pre-approvals.

Navigate to "Open Approvals" to review and approve requests. As an administrator, you can decide on requests and customize attributes, such as including chargeback information in the approval process.

In the Kubernetes Dashboard, we can see that a role and role binding has been created.

To approve a namespace creation request, you can use the following steps:

1. Request Access: Navigate to "Request Access" and find the option for "Local Deployment." Expand the menu and select "Administration" to view the administrators.

2. Approval Role: As the first approver and the person who requested the namespace, you have the authority to approve access requests. This role is tied to the business owner’s responsibilities.

3. Request on Behalf: You can request access on behalf of others, as long as they are logged in first. This system supports "just-in-time" access management.

The out-of-the-box Namespace as a Service workflow will generate a Namespace and RoleBindings, along with the groups needed to manage access. This is rarely enough to satisfy multitenancy requirements. You'll generally want to create at least a ResourceQuota, maybe NetworkPolicys, etc. There are several customization points where you can add your tasks.

Now create a new namespace:

Not every Namespace needs the side cars that's right, so the question is how do we collect that information and then how do we provision it into our cluster?

In Kubernetes environments, not all namespaces require sidecar containers. To manage this effectively, OpenUnison provides a method to collect and use information regarding the need for sidecars through custom attributes.

Custom Attributes

The form for onboarding a new namespace can have custom attributes added. These attributes can be as simple as a text box, or as complex as a drop-down with values loaded from an external API. Adding an attribute requires an update to the [openunison.naas.forms.new](<http://openunison.naas.forms.new/>)_namespace.additional_attributes section. For instance, if you wanted as users if they want to enable istio sidecar injection in your namespace, you could add:

openunison:
  naas:
    forms:
      new_namespace:
        additional_attributes:
        - name: istio_enabled
          # what will be displayed on the form
          displayName: Enable Istio Sidecars
          # validating regular expression
          regEx: ".*"
          # An error to provide the user if the regex fails
          regExFailedMsg: "Invalid istio configuration"
          # minimum number of characters
          minChars: 0
          # maximum number of characters
          maxChars: 0
          # should the value of this attribute be unique in OpenUnison
          unique: false
          # can by one of list, text, dynamicList
          type: list
          # if list, the values and labels in the form of DisplayLabel=value
          values:
          - Enabled=enabled
          - Disabled=disabled

Once the attribute is added to a form, it's available to workflows as both a request object with the name of the attribute and a user attribute. Attribute values are also available to approvers to provide additional context.

Namespace Labels and Annotations

When the namespace is provisioned, it can have custom labels and annotations. These annotations and labels can be generated from custom attributes, or created in a (workflow hook)[#workflow_hooks]. The value for an annotation or label must be preset in the request object. You add custom labels through name/value pairs in openunison.naas.workflows.new_namespace.namespace_request_labels and annotations through openunison.naas.workflows.new_namespace.namespace_request_annotations. For instance, to add the istio-injection label to a new namespace, you would add:

openunison:
  naas:
    workflows:
      new_namespace:
          namespace_request_labels:
            istio-injection: istio_enabled

Upgrading a Chart in OpenUnison 📈

To upgrade the chart without rerunning the entire OpenUnison control command, you can use Helm to apply the updates. Here’s how:

1. Run the Upgrade Command:

    helm upgrade <release-name> <chart-name> --namespace <namespace>
   

   • <release-name>: The name of the release you want to upgrade.

   • <chart-name>: The name of the Helm chart you are upgrading.

   • <namespace>: The Kubernetes namespace where the release is deployed.

LOOK "enabled Istio sidecars"

2. Developer Tools:

To integrate OpenUnison with other systems, such as Backstage, you can use developer tools to access API information:

1. Open Developer Tools in your browser and navigate to the "Config" section (typically located about three-quarters of the way down the menu).

2. Click on the "Response" tab to view the API response data. This data includes all metadata driven by the server-side, as the form is dynamically generated based on this metadata.

3. API Documentation: Access the API documentation via the Swagger docs on the OpenUnison website. This documentation provides detailed information on how to generate client code and interact with the APIs.

3. Customizing for Namespace Sidecars:

To update your cluster configuration to handle sidecar injection based on form data:

1. Update Namespace Labels and Annotations: Configure your Helm chart or deployment settings to include the logic for injecting sidecars based on the attributes collected from the form.

2. Integration and Automation: Use the provided API responses to automate form handling and resource provisioning, ensuring that your multi-tenant environment is configured according to the specified requirements.

• Add Labels: The configuration involves adding a label (istio_injection) that corresponds to the request attribute (istio_enabled) for sidecar injection. This label helps manage sidecar injection in namespaces based on user input.

• Annotations: While annotations are similar to labels, they are not necessary for this particular task but can be configured in the same manner if needed

  

  

  

  BOOM!!!! 🎊🎉

  You’ve achieved a significant milestone: automating the onboarding process for Istio-enabled applications.

OpenUnison provides hooks that allow the injection of code in the form of a workflow at various points during the process of onboarding a namespace. This helps protect against the Noisy Neighbour problem.

1. Workflow Hooks: The system offers hooks to inject code at different stages of the namespace onboarding process. This customization is documented in the "customizing the namespace onboarding process" section.

2. Resource Quotas: They will use these hooks to implement a resource quota as part of the namespace onboarding.

3. Multi-Tenancy with V Cluster: Referring to the Kubernetes and Enterprise Guide Third Edition, Marc mentions that in the V Cluster chapter, after creating a namespace, they deploy a V Cluster into the namespace using a workflow.

4. Example of Use: The workflows can be extended to handle more complex multi-tenancy setups, such as deploying V Clusters within namespaces.

To learn about all of the different ways in which you can customize the NaaS Onboarding process, check out the official documentation.

Let's create a resource quota with input on the form. Take the the sample yaml that's in there for the pre-run workflow.

apiVersion: openunison.tremolo.io/v1
kind: Workflow
metadata:
  name: create-resource-quota
  namespace: openunison
spec:
  description: creates a ResourceQuota object
  inList: false
  label: Creates a ResourceQuota
  orgId: internal-does-not-exist
  tasks: |-
      - taskType: customTask
        className: com.tremolosecurity.provisioning.tasks.CreateK8sObject
        params:
            targetName: $cluster$
            template: |-
                kind: ResourceQuota
                apiVersion: v1
                metadata:
                  name: resource-quota
                  namespace: $nameSpace$
                annotations:
                    tremolo.io/managedByGit: "$useGit$"
                spec:
                    hard:
                        cpu: "5"
                        memory: 10Gi
                        pods: 10
            srcType: yaml
            writeToRequest: "$useGit$"
            requestAttribute: git-secret-cluster-k8s-$nameSpace$
            path: /yaml/ns/$nameSpace$/resourcequotas/

We can dynamically manage the number of pods by user input during the namespace onboarding process.

To finalize the workflow creation, you need to ensure the following:

1. Syntax Validation: The Open Unison operator validates the syntax of your workflow. If there are any mistakes or incorrect configurations, you will receive an error when you submit it.

2. Post-Creation Steps:

   • Add the Attribute: First, you need to inform Open Unison to include the newly created attribute.

   • Invoke the Workflow: Then, you need to configure Open Unison to call the created workflow after the namespace is created.

     

     Let’s look at the process of adding a new attribute to the form and integrating it into the workflow:

     • Locate the Attribute Section: Find the section in the values.yaml file where attributes for the form are defined. Specifically, look for the existing istio_enabled attribute.

1. Duplicate and Modify: Duplicate the istio_enabled block and modify it to create a new attribute for the maximum number of pods:

   • Name: Set the name to quote_pods.

   • Display Name: Set the display name to "Requested Maximum Number of PODS."

   • Regex: Add a regular expression to ensure only numbers are accepted.

   • Failure Message: Customize the failure message to indicate the input must be a number.

   • Min and Max Characters: Set minimum and maximum character limits to restrict the input to valid numbers.

   • Type: Change the type to text and set values to an empty list.

2. Integrate Attribute into Workflow:

   • After defining the new attribute, update the workflow to handle this new input.

   • Use the post namespace create workflow hook from the documentation to ensure that after a namespace is created, the resource quota object is also created based on the user input.

Navigate to the dashboard to verify that the namespace has been created. Confirm the presence of a resource quota for the namespace, and ensure that there are 20 resources highlighted as inputted by the user.

Conclusion 🤓

In this blog, we learned about the concept of namespace as a service and how it can enable multi-tenancy within a Kubernetes cluster. We also saw the different ways in which we can use Open Unison for creating NaaS, and how we can create and approve permission for different users.

Overall, NaaS and multi-tenancy enable us to reduce cluster costs while maintaining a high level of security.

Thank you for reading!! 🤩

If you found this blog interesting, check out Part 1 and Part 2 of the live streams to hear the full conversation.😊

If you liked this blog, feel free to share it with your companions and stay updated with the latest developments in Cloud Native networking by following us on Twitter at EmpathyOps and checking out our website!

An access token is like a digital key that lets an app access an API. It tells the API that the token holder is allowed to do certain things. In this case, attackers used stolen access tokens to take over Facebook accounts, possibly accessing personal messages, photos, and other sensitive information.

Can you believe it? Almost 90 million Facebook users were affected by a breach that compromised access tokens to the platform!😱

In a more recent example, the popular AI platform Hugging Face reported a security breach on its Spaces platform, a community repository for AI apps. Hackers accessed authentication secrets, possibly compromising user data. And this happened just a few days ago.

Read more about the security breach here.

With the above two incidents, you’ve probably understood the importance of access tokens and the implications of them getting exposed. In today's digital world, managing these tokens well is essential to protect sensitive data such as personal information, credit card details, government issues documents, etc and maintain user trust.

Until now, we’ve used the word "Token" quite a bit - but what exactly is it? Let's understand tokens and their types.

Let's talk about Tokens 🔑

Tokens are pieces of data containing information to identify a user and determine if they are allowed to perform certain actions. In short, tokens help application systems with authorization and authentication.

Before understanding the various types of security tokens, let’s do a quick recap on Authorization & Authentication, and how the two differ. We’ll try and understand it with a fun example.

What is Authentication?

Authentication is the process of verifying who a user or device is. During this process, the user or device provides some proof, called an authentication factor, to confirm their identity. Is that confusing? Let’s try to make sense of it using an everyday example.

Imagine you’re going to the bank to withdraw some money. The clerk will ask for your ID to verify that you are exactly who you say you are. Similarly, when you buy a flight ticket, you need to show your passport to prove you are the person who bought the ticket before boarding the plane. These are two real-life examples of authentication, where your identity is confirmed.

When we talk about authentication in the software realm, the core concept is the same as the two examples we discussed above. However, the methods are different. Instead of using a physical government issues identification, you’d use tokens to validate the identity

What is Authorization?

In contrast to authentication, authorization is about checking what resources users or devices can access and what actions they can perform.

For example, when you buy a ticket for a show, the venue doesn't care about your identity. They just want to know if you are allowed to attend the show. To prove this, you use a ticket instead of an ID or passport.

In internet-based software apps, a common way to handle authorization is by using things called tokens. Once a user is logged in, the app starts focusing on what the user can do. This is where a token comes in—it holds details about what the user is allowed to do based on their identity. The system then uses this token to decide whether to grant or deny access to resources.

So, you see, authentication and authorization can sometimes get mixed up, which can be confusing.

But here's the key thing: authentication comes before authorization, but not the other way around.

While proving who you are might be enough to get access to something (that's authorization), just having permission doesn't always tell you who someone is.

So, about those tokens—in the world of web authentication and authorization, you might have heard the term "Bearer token." But what does it mean? How does it work? And why is "Bearer" in front of the token?

What's the deal with Bearer Tokens? 🙄

Bearer tokens are a way to show what kind of token is being used for logging in and getting access to resources within your system. They're often used with OAuth 2.0 and other token-based systems.

When you log in, you get a token from the server. This token proves you're logged in and lets you access protected parts of a web server. You usually put the Bearer token in the “Authorization” header of an HTTP request.

To show that the token is a “Bearer” type, you put the word "Bearer" before the actual token in the “Authorization” header.

Here's what the “Authorization” header looks like with a Bearer token:

Authorization: Bearer <token>

In this example, <token> is the actual token given to the client by the authentication server. The web server that gets the request can then check and validate the token. If the token is valid and authorized, it grants access to the requested resource.

Moving on, what kind of token should we use for Authentication or Authorization?

"Let's secure this API call with a token. Should I go with the ID token or the access token? The ID token looks better to me. I mean, if I know who the user is, I can make better authorization choices, right?"

This is not the correct way to choose a particular token for your use case. Choices based on your intuition may sound good, but what looks intuitive is not always correct. Using the wrong token can result in your solution being insecure.

Let’s take a closer look at these two types of tokens to better understand their role.

Show your ID - ID token? 🪪

An ID token is an artifact that proves that the user has been authenticated. It was introduced by OpenID Connect (OIDC), an open standard for authentication used by many identity providers such as Google & Facebook.

Consider the following diagram:

Here, a user with their browser authenticates against an OpenID provider and gets access to a web application. The result of that login process, based on OpenID Connect, is the ID token, which is sent to the app as proof that the user is authenticated.

This gives a basic idea of what an ID token is: proof that the user is authenticated.

An ID token is encoded as a JSON Web Token (JWT), a standard format that lets your app easily check its content, ensure it comes from the right issuer, and verify that no one has tampered with it. If you want to learn more about JWT, check out this article.

An ID token something looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsweyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsw

Of course, this isn't readable to the human eye, so you'll need to decode it to see what's inside the JWT.

You can use the debugger at jwt.io to do this.

Need access - Access Token? 🔓

Now that you know what an ID token is, let’s try to understand what an access token is.

Let's start by depicting a scenario where the access token is used:

Using the above diagram, imagine that a client application wants to access a resource. This resource can be anything like an API, database or something else that's protected from unauthorized access. The other two elements in the diagram are the user, who is the owner of the resource, and the authorization server. In this setup, the access token is what lets the client application access the user's resource. It's given out by the authorization server after the user successfully logs in and gives their consent.

The access token lets a client application access a specific resource to do specific actions on behalf of the user. This is called a delegated authorization scenario: the user lets a client application access a resource for them. For example, you can let your LinkedIn app access Twitter’s API to cross-post on both social platforms. Remember, you only allow LinkedIn to post on Twitter for you. You don't let it delete posts, change your profile, or do other things.

In short, the API needs to use that token to let the client application do what it needs to do with the resource.

This is the content of a decoded access token that follows the JWT format:

{
  "iss": "https://YOUR_DOMAIN/",
  "sub": "auth0|123456",
  "aud": [
    "my-api-identifier",
    "https://YOUR_DOMAIN/userinfo"
  ],
  "azp": "YOUR_CLIENT_ID",
  "exp": 1489179954,
  "iat": 1489143954,
  "scope": "openid profile email address phone read:appointments"
}

Alright! Now you know what an ID token and an access token are.

The access token is a bearer token, meaning anyone who holds it can use it. It acts as a credential to access protected resources. If malicious users steal access tokens, they can access protected resources by presenting those tokens to the server.

To reduce this risk, it's crucial to have security strategies. One method is to create access tokens with a short lifespan, valid for only a few hours or days.

When an access token expires, the client application can either prompt the user to log in again or use a refresh token to get a new access token from the authorization server.

Before we understand what is refresh token, an important concept is a short-lived token.

Short-lived tokens - great for security; bad for DX 👎🏼

Short-lived tokens, as the name suggests, have a limited validity period. This limitation is crucial for several reasons:

• Reduced Risk of Compromise: If a token is leaked, its short lifespan ensures that it quickly becomes useless to an attacker.

• Automatic Rotation: Systems can be designed to automatically issue new tokens at regular intervals, ensuring continuous security without manual intervention.

• Enhanced Traceability: Short-lived tokens can be logged and monitored more effectively, providing better insights into system access and usage patterns.

Refresh tokens - Bridge between Security & DX 🌉

As mentioned, for security reasons, access tokens might only be valid for a short time. Once they expire, client apps can use a refresh token to refresh the access token. A refresh token is simply a credential that lets a client app get new access tokens without asking the user to log in again.

Keeping Refresh Tokens Secure ✅

Short-lived access tokens boost our app's security, but there's a downside: when they expire, users need to log in again to get a new one. This frequent re-authentication can make your app seem annoying or hard to use, even if it's for their protection.

A refresh token can help you balance security with usability. Since refresh tokens usually last longer, you can use them to get new access tokens after the short-lived ones expire.

However, since refresh tokens are also bearer tokens, we need a plan to limit their use if they ever get leaked or compromised. Anyone holding the refresh tokens can get new access tokens whenever they want. "They" could be legitimate users or attackers.

To drive home the point about securing the refresh token, the recent Cloudflare breach underscores the importance of robust token management. When attackers exploited stolen credentials to access internal systems, the value of having a secure, centralized token management system became evident. By implementing a Security Token Service(STS), organizations can better protect their resources against unauthorized access and minimize the risk of breaches.

This is where Tremolo security's OpenUnisoncomes into the picture.

Implementing Security Tokens with Open Unison

How does OpenUnison, a security token service, make token management secure?

OpenUnison works with GitOps systems like Argo CD and Flux CD to keep your tokens safe. When you're using these systems, it's super important to handle tokens for accessing repositories and clusters securely. OpenUnison does this by:

• Issuing Short-Lived Tokens: Tokens are created with a short lifespan, so they don't stay around too long and reduce the risk of exposure.

• Token Validation: Tokens are checked to make sure they're being used by the right people. For example, if a pod using a token is deleted, the token stops working, which helps prevent unauthorized access.

• Token Rotation: Tokens are automatically changed regularly, so you're not stuck with static credentials. This ongoing rotation boosts security and lowers the chance of token leaks.

What happens when you start doing cross-cluster stuff where you have multiple clusters?

In environments with multiple clusters, Open Unison helps establish a common trust boundary by issuing tokens that are valid across clusters, facilitating secure communication and management.

Key Things OpenUnison Does for Securing Tokens 👀

• Token Expiration: Make sure tokens don't last too long to cut down on the risk of unauthorized access.

• Automatic Rotation: Set up systems to automatically issue and rotate tokens so you don't have to rely on static credentials.

• Robust Validation: Use tools like OpenUnison to check tokens and make sure only the right people are using them.

• Monitoring and Logging: Keep logs of token usage to watch for any unusual activity.

If you want to see some of this in action, check out this video of OpenUnison in action & interesting conversation with Marc, CTO @ Tremolo Security, Marino, and Aakansha. Also, feel free to follow the docs via GitHub!

Finally, we did a live stream on Namespace as a Service which was also an extension to security tokens. Catch the recording here!!!

Cheers and thanks for reading 😊!

These containers need to be able to communicate with each other, as well as with the other parts of the infrastructure, such as external services and databases. Kubernetes networking allows this communication to happen seamlessly and securely. What makes Kubernetes network a challenge, is that it’s a very distributed network. There are a ton of “micro applications” running inside a cluster, and they all need their separate network configurations.

The Need for Networking

Before getting onto the way networks are handled in a cloud-native system such as Kubernetes, let us first try and understand why we even require robust networking.

Let’s say that we have a particular device. Now this device could be absolutely anything. It could be your Phone, your laptop, your smart TV, smart bulbs, or anything else. Every single one of these devices has its little internal network, and we may not have direct access to a device's internet network. And that's because it's a very highly customized and tuned network. After all, that network acts as a bus, where multiple components communicate with each other to effectively give some sort of output.

Now, what do I mean by these highly customized networks? Imagine an entire smart home setup. What are all your smart bulbs and smart TVs connected with? The answer is a network. It could be a wireless or a wired network. These networks have been configured in a very special way so that all these different devices can connect, and work seamlessly.

Let’s take another example. What happens when you access a YouTube video on your phone? Behind the scenes, there might be some inter-process communications going on. And it's happening in its little network before all of this data gets translated into a proper video format that you can understand. And this is the output that we see on a YouTube video.

So, once we go beyond our phone or the home network, we have different devices that need to be able to communicate with each other. And over nearly four decades worth of innovation, we've seen how networks have evolved and gone from being public, to private, and then again from private to public. But what are these special kinds of devices that enable us to communicate with people globally? That’s where we have some kind of an Intermediate Device that can help enable this kind of wide-area communication.

The Role of Intermediate Devices

Your device right now is connected to some form of network. It might be a wireless network such as your cellular network which provides 5G connections, or it might be your home Wi-Fi network. What ends up happening is your device ends up talking to some sort of core device that knows how to get you and your device to other networks, to other locations, to other destinations, because your device doesn't know about the rest of the network.

There could be an entire big world beyond your device but it doesn't know about this global scale. So there are devices in between your device whether it’s your phone, your laptop, your TV, or anything else. The service that you are trying to access and those intermediary devices are moving your requests throughout the network to make sure they get to their destination in the fastest manner possible while still providing you with the result on time.

When it comes to these intermediary devices, the physical devices that exist at data centres, in cloud environments, at points of presence (POPs) or service provider locations they control a big aspect of the internet. Now, when we think about networks and the connectivity streams themselves, it's very, challenging to navigate or build on top of those existing networks because there are so many different constraints we have to consider. We need to consider factors such as what the physical world is doing, or the way the physical world moves our packets around.

Now, going back to those intermediary devices, let's call them routers and switches because they're effectively the ones responsible for moving packets around very quickly and knowing how to decide where to move those packets to is effectively the function of a router. A router is usually paired up with a switch so we can connect even more devices to a network.

Cloud Native networks

Now, let’s talk a bit about how networks are being handled in the cloud-native systems. When we get into the cloud native landscape, there are several different areas that we want to focus on. Those several different areas still depend on the physical network.

We talked about the importance of various devices such as routers and switches in a physical network, and how it connects the entire world. But now, let’s take a look at the cloud native and Kubernetes ecosystem.

Let’s say you want to provision a Kubernetes cluster on a cloud provider such as AWS, GCP or Civo. What happens when you press the “create cluster” button? What you can see, is the state of the cluster, and its nodes. We can’t see what’s going on in the background. However, if we dig around the cloud dashboards a bit, we can see exactly what’s going on.

The cloud provider is creating a couple of VMs, which will act as nodes for your clusters. It might also create some storage volumes depending on how you configured your cluster. And there might even be a brand new load balancer created. That’s all well and good, but the question that we have to ask is, how are all these different resources getting connected into this single Kubernetes cluster?

We already saw that we need to connect these tons of physical devices to create a network. So how is Kubernetes able to do it in such an automated way? If it needs physical networks to connect everything, then where are those physical devices that are connecting the cluster? Well, the answer is, there aren’t any physical devices. But the clusters are connected somehow.

Virtual Networks

This is where the entire concept of virtual networks comes into play. Before diving into virtual networks, let’s come back to the concept of virtualization. We know that Virtual machines and containers are created by a neat technology called as virtualization. This lets us split one physical computer into multiple virtual computers. You can think of it as a way to create multiple computers from a single computer’s hardware.

So, taking a short look at how virtualization is achieved. We have a host computer, i.e the physical computer. We install a piece of software on top of the physical computer which we call a Hypervisor. This hypervisor is what we use to create hundreds of virtual machines or containers i.e. split the physical computer into multiple sub-compters.

Virtual networks follow the same concept. Instead of using multiple physical routers or physical switches, you can simply use one single powerful router or switch and split this into multiple smaller ones using virtualization. Now using these virtual networks, we can create hundreds or thousands of other networks to work with.

Now, before we look at the networks in a Kubernetes cluster, we need to look at one more thing. The Linux Kernel has an amazing feature called namespaces which essentially allows us to isolate processes. This is what containers use. Now, to separate networks, we have a network namespace as well. This simply separates the network, so on a single Linux host, you could have a lot of separate networks. All of these networks can have their own routers, switches, and other network interfaces. From a networking standpoint, every single container is just a network namespace

Now, we know that Kubernetes is a container orchestrator which means that at the end of it day, its job is to run containers. We also know that Kubernetes runs the containers inside tiny pods. For a Kubernetes environment, these pods are what we will be calling as the network namespaces.

One thing that we need to highlight is that the entire paradigm of virtual networks is completely software-defined. That means we can very easily automate their creation, in contrast to if we were using physical interfaces to connect everything. That is where virtual networks are such a big and important aspect of Kubernetes and connecting the world.

Alright, so we have now created the virtual network namespaces and now the pods inside the cluster have a network that can connect to other networks. But how do we make sure that all these network namespaces connect to the correct networks? We already know that containers are ephemeral which means after some time, they will get destroyed and recreated. After they get recreated, the IP address assigned to them changes.

Since the IP address changes, we most certainly cannot use the IP address to define which other networks should they connect to. So, we’re going to need a DNS service within our Kubernetes cluster.

DNS

Before diving into DNS, let’s take a bit of an analogy. We all have phones. How do we make a phone call to another person? We have to dial their phone number. Now imagine if you had 100 friends who you talk with. You would need to memorize 100 different phone numbers. And even if you were able to do that, there is a chance that you enter a wrong phone number. So instead we have something like a phonebook, where we save the phone numbers along with the contact name.

A DNS works in the same way as a phonebook. It stores a bunch of IP addresses and assigns the proper names to those addresses. Let’s say you wanted to head over to google.com. You enter the URL in your browser and hit ENTER and the page loads. That’s great and all but what just happened?

On the backend, your browser saw that you wanted to go to google.com, but it did not know what’s the IP address of this URL. So what it does, is it looks up the IP address of the entered URL in a DNS server. From there, it will match the URL with its IP address and once your browser knows which IP address google.com exists, it will take you there.

Since in a Kubernetes environment everything is ephemeral, relying on hardcoded IP addresses will not work. Hence we need a DNS service that can automatically detect the newly created networks and assign them the proper name. In a Kubernetes cluster, you would usually see CoreDNS as the most common DNS service. However, DNS is only part of the story when it comes to enabling the pods to communicate. The other half of the story is Kubernetes Services. First, let’s take a look at what is a Container Networking Interface (CNI).

Container Networking Interface (CNI)

In the previous section, we mentioned that the DNS services make sure that the recreated network is reachable. But when this network is created or re-created, what assigns it the IP address in the first place?

To create a standardized way to handle networks in Kubernetes, there was a specification which was introduced called as the Container Networking Interface(CNI). This specification is just a bunch of rules and principles that need to be followed when we create a networking solution for a Kubernetes cluster.

Various CNI plugins have been created and refined over the years. Some of the popular examples of these CNI plugins include Calico, Cillum and Flannel. They all do essentially the same tasks, but each one of these CNI plugins has its way of doing things and might provide different features.

Kubernetes Services

Now, for the Kubernetes pods to be able to communicate with each other, we need to expose those individual pods through Kubernetes objects that we call a service. In the most simple terms, a service is a way to enable the pod to communicate either with the outside world or with other pods. There are a total of three main types of services. Let’s take a look at them in brief.

• ClusterIP: A clusterIP service is just a way to allow pods to communicate with other pods inside the cluster. It’s an internal network for the pods.

• NodePort: NodePort just ties your pod to a specific node. This can be limiting because your nodes can come and go pretty easily, and you don't want to be in a situation where you lose a node. If that happens, you've lost access to your app.

• Loadbalancer: A load balancer will just decide how to distribute the incoming traffic across the available Kubernetes nodes. Duplicates of one pod can exist on different nodes as well, and a load balancer will help distribute the traffic among those copies.

A service in Kubernetes is an actual way to translate DNS. It's not directly called DNS, but it's a way to translate DNS into pod IPs. They use a concept of labels and selectors to effectively map the service to specific pods that you might have deployed.

Once we have these pieces in the mix, we’ve got pretty much everything we need to get going for a Kubernetes cluster. There are still a few elements that we are missing for security considerations. And that is where we would use things like a Service Mesh, or an API gateway. They are all huge topics in themselves, so let’s take a high-level overview of them.

Service Mesh

Before delving into service mesh, it's essential to understand how applications communicate. Typically, we interact with applications via HTTP rather than directly pinging their IP addresses. HTTP is simply a protocol that you can use for communications. Service A communicates with Service B, often using HTTP requests like GET to retrieve data. This communication can involve other protocols, but HTTP is predominant.

HTTP operates at layer 7 of the OSI model, encompassing all network layers, from the physical to the application layer. While the network layer primarily focuses on routing, it lacks the intelligence necessary for sophisticated operations.

Layer 7 offers substantial benefits, such as the ability to pass authentication tokens, filter requests, and even control access through rate limiting. Filtering at the IP or hostname level, or lower layers, is limited in this regard. Layer 7 also introduces identity and authorization, enhancing security.

Service mesh builds on these concepts, deploying a control plane that interacts with the Kubernetes control plane and influences the architecture. The data plane, existing as proxies within Kubernetes, facilitates routing, filtering, and authorization. An ingress gateway (incoming traffic) and an egress gateway (outgoing traffic) control traffic in and out of the cluster, while mini proxies within the cluster manage individual services.

Service mesh not only adds intelligence to routing but also assists with blue-green deployments, canary launches, and resilience. It enables circuit breaking to mitigate failures within an application, ensuring partial functionality. Kubernetes takes charge of reconciliation, automatically correcting deviations from the desired state.

Kubernetes communicates with cloud providers' APIs to handle node failures, reprovisioning nodes when needed. This process automates networking, from the physical layer to the service mesh, offering a seamless experience. This automation extends to cloud providers like AWS, where clusters, load balancers, and EC2 instances are provisioned behind the scenes.

API Gateway

An API gateway typically sits atop a load balancer, where the load balancer listens for external requests while the API gateway handles request processing logic. This concept predates Kubernetes and is versatile, and applicable to various environments, including VMs, functions, containers, or external entities.

The API gateway serves as the primary entry point to access APIs, similar to a service mesh but centralized at the cluster or environment edge. In essence, a service mesh is an evolution of the API gateway, running universally across all workloads and offering the same capabilities.

As your needs evolve, transitioning from an API gateway to a service mesh may be necessary, especially when dealing with intricate service-to-service communication and dependencies.

In today's Kubernetes-centric landscape, service meshes like Istio accommodate both VM and Kubernetes workloads, serving as the API front end for both.

However, in purely virtual machine environments, sticking with API gateways might be more fitting due to service coupling and functionality considerations.

API gateways provide additional features like rate limiting, which ensures that services don't get overwhelmed by limiting the number of incoming requests over time. This prevents service outages caused by a sudden influx of requests.

Additionally, API gateways act as front doors and can function as web application firewalls, filtering inbound traffic based on policies. They can also handle TLS termination and authentication, simplifying the authentication process by connecting with other systems seamlessly.

Conclusion

In summary, networking is the backbone of modern technology, enabling communication across devices and applications. Within Kubernetes, a dynamic container orchestration platform, networking takes centre stage, allowing containers to interact seamlessly. This article explores the critical role of networking in Kubernetes and the solutions it employs.

Kubernetes faces the challenge of managing myriad microapplications, each with unique network requirements. To address this, it harnesses virtual networks and Container Networking Interfaces (CNI) for automated network management. These virtual networks adapt to the ever-changing container landscape, ensuring uninterrupted communication.

DNS services are crucial for translating human-readable URLs into IP addresses and facilitating pod communication within clusters. Kubernetes services, including ClusterIP, NodePort, and LoadBalancer, further enhance connectivity for internal and external traffic.

To address advanced networking and security needs, Kubernetes offers service meshes and API gateways. Service meshes like Istio enable intelligent routing, filtering, authorization, and support features like blue-green deployments. API gateways serve as centralized entry points, handling tasks like rate limiting, web application firewall functionality, TLS termination, and authentication.

As Kubernetes continues to shape the cloud-native landscape, mastering its networking intricacies is pivotal for organizations seeking reliability, security, and scalability in their applications and services.

Thanks for reading!

If you liked this blog, feel free to share it with your fellow companions and stay updated with the latest developments in Cloud Native networking by following us on Twitter at EmpathyOps and checking out our website!

What are MicroVMs?

At its core, a MicroVM is a lightweight virtual machine designed to provide security and isolation akin to traditional VMs while maintaining the resource efficiency of containers. Unlike traditional virtualized or emulated computer systems, MicroVMs are optimized for specific tasks and have a minimal attack surface.

Key Features of MicroVMs

1. Security: MicroVMs achieve security through the use of cgroups and seccomp BPF, ensuring that all processes are isolated and restricted, reducing the risk of security breaches.

2. Speed: These tiny virtual machines are incredibly fast, with benchmarks boasting less than 125ms to launch 150 MicroVMs per second.

3. Scale and Efficiency: MicroVMs have a memory footprint smaller than 5MiB, allowing for a high degree of consolidation on a single server, leading to resource efficiency.

Supported Devices

MicroVMs are designed to support a limited set of devices, following a philosophy of "less is more." They prioritize paravirtualization and use Virtio devices, which can significantly reduce hypervisor bloat and result in faster startup times. The devices emulated can vary depending on the specific implementation.

Anatomy of a MicroVM

1. Volumes: Each MicroVM requires a root volume to boot. These volumes are typically implemented as rawfs files or block devices. While working with volumes can be cumbersome, overlay filesystems and device mappers can simplify the process.

2. No BIOS or Bootloader: Depending on the implementation, MicroVMs may not have a BIOS or bootloader. Instead, the kernel executes directly.

3. API Server: Most MicroVM implementations come with a built-in API server accessible via a socket. This allows for configuration and operational actions on the MicroVM instances.

4. Metadata Service: Some implementations offer a metadata service similar to AWS's instance metadata service. This enables the transfer of information from the host to the guest, making it useful for cloud-init and passing secrets.

Why Should You Care About MicroVMs?

MicroVMs offer a compelling solution for maximizing resource utilization on your infrastructure. By reducing overhead and maintaining strong security and isolation, they enable you to run more workloads on the same hardware.

Use Cases

1. Workload Isolation: MicroVMs provide superior isolation compared to containers, making them ideal for workloads with regulatory, operational, or data privacy requirements.

2. Isolated Build Pipelines/Runners: MicroVMs can be used to create isolated environments for building and testing code, enhancing security and reproducibility.

3. Short-Lived Testing/Preview Environments: When you need to quickly spin up test environments for software development or testing, MicroVMs offer a lightweight and efficient solution.

4. Short-Lived Jobs: Tasks like data processing or batch jobs can benefit from the fast startup times and efficient resource usage of MicroVMs.

MicroVM Implementations

There are two primary MicroVM implementations worth mentioning:

1. Firecracker (FC)

• Developed by AWS

• Designed for ephemeral compute

• Smallest device model

• Utilizes the Jailer for increased security

• Linux guests only

2. Cloud Hypervisor (CH)

• Developed by Intel, Alibaba, and others

• Offers a more generalized and feature-rich approach

• Supports a larger device model, including PCI and more Virtio devices

• Suitable for both Linux and Windows guests

To better understand where MicroVMs fit into the virtualization landscape, let's compare them to containers and traditional VMs:

MicroVMs

• Design: Lightweight isolated virtual machines with their own kernel, guest operating system, and virtualized hardware.

• Isolation: Provide strong isolation, with each MicroVM running in its own virtual machine instance.

• Performance: Offer small overhead compared to traditional VMs and quick startup times.

• Use Cases: Ideal for running untrusted and multi-tenant workloads that require strong isolation and security.

Containers

• Design: Lightweight, isolated runtime environments that share a host operating system kernel.

• Isolation: Provide application-level isolation, sharing the underlying host operating system and kernel.

• Performance: Efficient resource utilization and rapid startup times by leveraging the host operating system and resources directly.

• Use Cases: Great for deploying and managing applications consistently across different environments, with a focus on scalability and agility.

Traditional VMs

• Design: Full-fledged virtualized instances of physical hardware.

• Isolation: Provide complete isolation between the host system and the guest operating system.

• Performance: Higher resource overhead compared to containers, with slightly longer startup times.

• Use Cases: Suitable for scenarios that demand complete isolation between workloads.

In summary, MicroVMs combine the strengths of both containers and traditional VMs while mitigating their respective disadvantages. They offer isolation and security similar to VMs while maintaining the efficiency and rapid deployment capabilities of containers.

Conclusion

MicroVMs are transforming the serverless space, allowing cloud providers to run more workloads with less overhead. They provide the security and isolation of traditional virtual machines while offering the resource efficiency and rapid deployment capabilities of containers. As technology continues to evolve, MicroVMs prove to be a promising solution for a wide range of use cases in the world of cloud computing and virtualization.

Also, check out some end-user testimonials

Thank you for reading!

If you liked this blog, feel free to share it with your fellow companions and stay updated with the latest developments in Cloud Native networking by following us on Twitter at EmpathyOps and checking out our website!