CSAR and SBOM for Airgap Kubernetes: Strategies for Enterprise Deployments

How to leverage the strengths of CSAR and SBOM to move images to private registries in airgapped environments?

CSAR focus on how to deploy and manage applications, while SBOM secures what is in them. What if we combined both to orchestrate securely across public, private, and airgapped environments?

DevOps and Kubernetes in airgap environments are challenging, and in this post, we'll explore some ideas of strategies for deploying cloud-native apps in Kubernetes in airgap environments. One of the bigger challenges I've noticed is still moving images to private registries; it's a roadblock that continues to trip people up, especially in airgapped environments. Security is another big concern in these environments, and it's important to have a strategy in place to ensure that your Kubernetes cluster is secure.

I aim to explore how we can leverage the strengths of different tools and frameworks to avoid creating from scratch and use well-known standards and frameworks to solve this problem. I'll be looking at how we can combine the strengths of CSAR and SBOM to extend them and create a new approach to move images to private registries in airgapped environments. I'll also explore some of the alternatives available today and how they can be used to solve this problem.

• Why the tools we have today are not enough to solve this problem?

• What are the challenges, what alternatives do we have to move images to private registries in airgapped environments?

These are some of the questions I'll be exploring in this post. I'll also be sharing some ideas on how we can leverage the strengths of different tools and frameworks to create a new approach to move images to private registries in airgapped environments. Keep reading to learn more!

The Challenge of Moving Images to Private Registries in Airgapped Environments

While we have amazing tools to deploy cloud-native applications, the process of moving images to private registries is still a challenge; think about it: before, on bare-metal environments, or VMs, managing RPMs or DEBs was (is) also a challenge, I faced this problem in the past, when I was working in a project that required to install a Vanilla Kubernetes cluster in a private network, I had to install a lot of packages in a lot of servers, and the servers were in a private network, so we had to download the packages in a server with internet access, then move the packages to the private network, and install the packages in the servers. Well, we live in cycles, right? Now, the story is the same, but with containers, we have to download the images from a server with internet access, then move the images to the private network, and then deploy the images to the servers.

In fast-paced and agile enterprises, where business agility drives multiple value streams, each with unique requirements, dependencies, and security demands, managing Kubernetes or containerized clusters across teams can feel overwhelming. The more projects and clusters, the more time-consuming and error-prone the process becomes. Worse, moving images across networks can expose your systems to serious security threats. Now imagine doing all of this in airgapped environments—no internet access, and even tougher challenges. You need a solution to move images to private registries seamlessly, without compromising security. The stakes are high, and it's time to rethink how we tackle this.

We can summarize the challenges of moving images to private registries in airgapped environments as follows:

• The first challenge is moving images to private registries. In airgapped environments, you can't pull images from public registries like Docker Hub or Quay.io. You need to move images to a private registry in the airgapped environment.

• The second challenge is security. In airgapped environments, security is a top priority. You need to ensure that your Kubernetes cluster is secure and that you're not exposing your cluster to security risks.

• The third challenge is orchestration. In airgapped environments, you need to orchestrate and manage dependencies. You need a way to track dependencies and vulnerabilities and ensure that your deployments are secure.

What alternatives do we have to move images to private registries in airgapped environments?

Alternatives to Move Images in Airgapped Environments

In modern enterprise environments, particularly airgapped and hybrid ones, efficient package management and secure software distribution are critical. I was wondering, how could some of the frameworks and tools that we have today help us to solve this problem. CSAR, SBOM, Docker Compose, Helm, Kustomize, ArgoCD, and many other, each of these tools has unique strengths, addressing various aspects like dependencies, vulnerabilities, orchestration, and inventory management.

These cannot help us to tackle the problem of moving images to private registries in airgapped environments. But what if we could combine the strengths of these tools to create a new approach to move images to private registries in airgapped environments?

Why the tools we have today are not enough to solve this problem?

Why Helm, Kustomize, and ArgoCD are not enough?

Restricted environments like airgapped or high-security ones require a different approach to conventional software deployment. Firstly, standard tools like Helm, Kustomize, or Docker Compose are not designed to handle the complexities of airgapped environments. They cannot move images to private registries in airgapped environments, track dependencies, and vulnerabilities, and orchestrate deployments across multiple environments. They are focused only on defining and deploying applications, not on managing the complexities of airgapped environments.

Secondly, the alternatives on top of current solutions are not enough to solve this problem. Tools like Crane, and Skopeo provide ways to move images between registries, but they cannot track dependencies and vulnerabilities, orchestrate deployments, and manage software packages securely in airgapped environments. Tools like Hauler, and Zarf are focused on packaging and distributing assets in airgapped environments, these are great alternatives but are tightly focused on specific non-standard package formats that may not be suitable for all use cases.

Thirdly, the lack of transparency and security in the software supply chain, combined with the absence of a unified solution presents a significant challenge. With mandates like the White House’s push for enhanced Software Supply Chain Security, organizations need a way to securely move images to private registries in airgapped environments, track dependencies, and vulnerabilities, and orchestrate deployments across multiple environments. A comprehensive solution that ensures security, transparency, and compliance—while managing software packages seamlessly and securely in airgapped setups—is essential.

CSAR and SBOM: Two Frameworks, Two Solutions

The Cloud Service Archive (CSAR) and Software Bill of Materials (SBOM) frameworks are two solutions aimed at solving different problems. CSAR focuses on orchestrating deployments of network functions, while SBOMs, like CycloneDX and SPDX, ensure security and transparency by providing a detailed inventory of components. But as organizations move toward stricter security practices, airgapped environments, and hybrid clouds, a new approach is needed; one that blends the strengths of both.

CSAR packages simplify orchestration and deployment in NFV environments, but they don't track dependencies or vulnerabilities. SBOMs (CycloneDX/SPSX) excel at security and compliance, listing components and vulnerabilities. But they don't provide a way to orchestrate the inventory and dependencies for deployments. CSAR's role is about how to deploy, while SBOM's role is what is deployed and how to manage its risks. A new approach is needed to combine the strengths of both frameworks. This approach should provide a way to manage and set up a private registry, move images to it, and orchestrate deployments while tracking dependencies and vulnerabilities. It should also support airgapped environments and hybrid clouds.

An inventory of components and orchestration to move images to private registries in airgapped environments has become a necessity and is a must-have for modern enterprise projects. I was thinking about how to solve this problem, with either a tool or a service, and I came up with the idea of building a tool that can help with this. The tool is part of the K1s project, and it's called K1s Airgap SABOR (Software Airgap Bill of Materials Resolver). K1s' SABOR is a tool that helps you move images to private registries in airgapped environments. It's a simple tool that you can run on your local machine, and it will help you move images to private registries in airgapped environments.

Before we dive into the details of SABOR, let's take a look at the challenges of deploying Kubernetes in airgap environments, and what options you have.

Alternatives to Move Images to Private Registries in Airgapped Environments

There are several alternatives to move images to private registries in airgapped environments. Here are some of the most common ones:

• Docker Save and Load: You can use the docker save and docker load commands to save images to a tarball and then load them into a private registry (as demoed in my video here). This is a manual process and can be time-consuming.

  • If you don't have or don't want to install Docker (or any other tool) you can do it with curl! Yes, check this video demo I made here.

• Crane and Skopeo: Crane "is a tool for interacting with remote images and registries". Skopeo is a tool that helps you copy images between registries. You can use Crane or Skopeo to move images to private registries in airgapped environments.

• Hauler: Hauler is a tool "designed and built to solve the challenges of collecting, packaging, and distributing assets in airgapped environments".

• Zarf: Zarf is a tool that "provides the ability to package necessary components from the internet and securely deliver all of the files and dependencies needed to run an application in a disconnected environment" (airgapped).

I ordered this list by the complexity of the tool, from the simplest to the most complex (based on my experience). Additionally, on enterprise projects, you may need to use a combination of these tools to move images to private registries in airgapped environments; in these kinds of projects, due to the security restrictions the ISV (Independent Software Vendor) will probably share with you a set of images that you will have to move to your private registry, or in self-service projects, the ISV and System Integrators will have to move the images to the private registry, but they may have restricted access to the Kubernetes cluster, so they will not be able to use tools that require cluster role permissions, some of the tools mentioned above require cluster role permissions, to deploy operators, or add CRDs.

There is this other project incubating in the Linux Foundation, called Sigstore, that aims to provide a way to sign and verify software artifacts. Singing and verifying software artifacts is a must-have in airgapped environments.

Another great initiative is BOM (Bill of Materials), a Kubernetes Special Interest Group (SIG) that aims to provide a way to track dependencies and vulnerabilities in Kubernetes deployments.

Also, Zarf is a great project leveraging the power of the SBOM framework, but I found it a bit complex to use and would be hard to integrate into a pipeline already in place in enterprise projects, it is focused on packaging and delivering assets in airgapped environments.

As I said, why not leverage the different strengths of these tools to create a new approach to move images to private registries in airgapped environments?

SABOR: A New Approach Extending SBOM and CSAR to Move Images in Airgapped Environments

Recognizing the strengths of both CSAR and SBOM, the airgap tool I'm building takes a hybrid approach.

SBOM strengths:

SBOMs, like CycloneDX and SPDX, address these limitations by providing a transparent view of software composition. They focus on the what; tracking all software components, their versions, dependencies, and potential security vulnerabilities. In airgapped or high-security environments, knowing exactly what's inside each software package is critical for managing risks and maintaining compliance.

• Security Focus: SBOMs shine when it comes to identifying vulnerable components and managing risk. With increasing software supply chain attacks, having this transparency is crucial.

• Compliance and Auditability: SBOMs help organizations meet regulatory and industry standards by providing detailed insight into software components.

Limitations of SBOM:

• Lack of Orchestration: SBOMs track what is inside a package but don't help deploy or manage the how or where of that package across cloud environments.

• Not Built for Distribution: SBOMs don't inherently provide mechanisms to package and distribute software effectively, particularly in complex, hybrid, or airgapped environments.

CSAR: The Orchestration Powerhouse with Limitations

CSAR packages are a solution designed to simplify the deployment and lifecycle management of network services, especially in NFV (Network Function Virtualization) environments. They bundle everything needed for deploying these services; service descriptors, configuration files, and scripts; making it easier to orchestrate and deploy complex systems like Virtual Network Functions (VNFs) across cloud environments.

However, CSAR has limitations:

• Deployment Focused: While it's excellent at managing the how and where of deployments, CSAR doesn't track the what; it doesn't list or manage software components, dependencies, or vulnerabilities.

• Limited Security Insight: CSAR doesn't provide a detailed breakdown of software components, leaving gaps when it comes to tracking software risks or ensuring compliance.

How does SABOR extend all of these strengths?

Recognizing the strengths of both CSAR and SBOM, the airgap tool I'm building takes a hybrid approach. By leveraging SBOM data, the tool will provide a full breakdown of components while allowing users to securely package and distribute software without internet access. This is particularly vital for industries like telecom or defense, where security and compliance are paramount.

SABOR will:

• Extend SBOMs by not just tracking the what but also leveraging that information to create secure, compliant packages for airgapped and hybrid cloud environments.

• Focus on Distribution: This tool will handle the how and where by orchestrating package distribution across public clouds, private clouds, and airgapped environments. This addresses CSAR's strength in orchestration while extending SBOM's transparency to a more practical application.

• By leveraging SBOM data, the tool will provide a full breakdown of components while allowing users to securely package and distribute software without internet access. This is particularly vital for industries like telecom or defense, where security and compliance are paramount.

• Extend CSAR's orchestration capabilities to include SBOM data, providing a comprehensive solution for managing software packages across multiple environments.

Future Enhancements: Orchestrating Across Multiple Environments

Looking ahead, this tool will not only package and secure software components but also orchestrate their distribution:

• Multi-Cloud Compatibility: It will support deployment in public and private clouds, allowing organizations to seamlessly move packages between environments.

• Hybrid Cloud Orchestration: Enterprises working with a mix of cloud and airgapped environments will benefit from centralized orchestration, ensuring that the right packages are deployed in the right places, with full transparency and control over their contents.

As software supply chains become increasingly complex, and as organizations move toward hybrid cloud and airgapped solutions, there's a growing need for tools that offer both security and orchestration. CSAR helps with orchestration, but it lacks transparency and security insights. SBOMs provide transparency but don't manage how or where packages are deployed.

BONUS: Recipies on Current Tools in Action

Let's explore a hypothetical example of how we could use CSAR and SBOM to move images to private registries in airgapped environments and orchestrate deployments.

CSAR: Orchestrating Deployments

CSAR packages simplify orchestration and deployment in NFV environments, but they don't track dependencies or vulnerabilities. They focus on the how of deployments, not the what. CSAR intentionally leaves out software composition details, focusing instead on orchestrating deployments. This makes it easier to manage complex network services but leaves gaps in security and compliance.

You could deploy containers with CSAR using a specific VNFM (Virtual Network Function Manager) that supports containers, but it is not the best tool for that because of the complexity, we want to get stick to Kubernetes, hence it is better to use Helm, or Kustomize for that.

How could we leverage the strengths of CSAR to move images to private registries in airgapped environments? Again, this is not the focus of CSAR, but it is a common problem that we face in enterprise projects, let's walk through a simple hypothetical example where you're deploying a web application using a CSAR package with a TOSCA template. The web app needs two things:

• A database.

• An application server that connects to the database.

TOSCA Template Breakdown

This template example will describe:

• Node templates: The components (like the database and app server).

• Relationships: How these components connect.

• Dependencies: The order in which things need to happen.

Here's what the TOSCA template might look like in a simplified version:

topology_template:
  node_templates:
    my_database:
      type: Database
      properties:
        db_name: my_app_db
        db_user: user123
        db_password: pass123
      interfaces:
        Standard:
          create: db_setup_script.sh # This script sets up the database

    my_app_server:
      type: WebApplication
      properties:
        app_name: my_web_app
        app_port: 8080
      requirements:
        - database_connection:
            node: my_database # This tells the app to connect to the database
      interfaces:
        Standard:
          create: app_setup_script.sh # This script installs and starts the app

What Happens When the Orchestrator Follows This Template

Orchestrator reads the TOSCA template: It starts by identifying the two components: my_database and my_app_server.

Step 1: Set up the database:

• The orchestrator sees that the database (called my_database) needs to be created first.

• It runs the db_setup_script.sh (defined under the create interface) to set up the database with the right name and credentials (my_app_db, user123, pass123).

Step 2: Set up the application server:

• Next, the orchestrator looks at the my_app_server node and sees that it needs the database to be ready before the app can be set up.

• The template says the app server should connect to the database (my_database), so the orchestrator knows to establish that link.

• After the database is ready, the orchestrator runs the app_setup_script.sh to install and start the web application.

How the Orchestrator Knows the Sequence

The orchestrator knows:

What to do first because the app server depends on the database (defined in the requirements section: database_connection: my_database). How to do it because the TOSCA template specifies the exact scripts to run for each component (like db_setup_script.sh for the database and app_setup_script.sh for the application).

Summary of the Orchestrator's Process:

1. Deploy the database first.

2. Wait for the database to be ready.

3. Deploy the application server after the database is up.

4. Make sure the application server can connect to the database.

This sequence is clearly laid out in the TOSCA template, and the orchestrator follows these instructions step by step to ensure everything works properly.

You may be wondering, "hey, this looks like a Helm chart or Docker Compose file!" Yes, it is similar, you can think of TOSCA in CSAR as a more complex and cloud-native version of Docker Compose. Both tools help you define and orchestrate multiple services, but they operate at different levels. Docker Compose focuses on containers, while TOSCA/CSAR works at a higher level, including virtual machines, networks, and cloud services.

One advantage of TOSCA VNF packages is that they can be deployed across different cloud environments, and you can package everything you need for a network service in a single package, including your container images. If you ned to move images from different registries in airgapped environments, you will need to extend the logic of the TOSCA template to move the images to the private registry in the airgapped environment, and this is the problem we are trying to solve.

To extend the TOSCA template to include the necessary components for moving images between registries, we can add node templates representing the source and destination registries, as well as the logic to move the images. This approach allows us to define relationships between components and orchestrate the movement of container images in a declarative way.

Here's how we could extend the TOSCA template to include image transfer:

Extended TOSCA Template Example

topology_template:
  node_templates:
    # Application Deployment Node
    web_application:
      type: tosca.nodes.WebApplication
      properties:
        name: "MyWebApp"
        version: "1.0"
        container_image: "myrepo/webapp:1.0"
      requirements:
        - host: web_server
        - registry_pull: source_registry
        - registry_push: destination_registry

    # Source Docker Registry
    source_registry:
      type: tosca.nodes.Registry
      properties:
        name: "Source Docker Registry"
        url: "https://source-registry.com"
        credentials: 
          username: "source_user"
          password: "source_password"
      interfaces:
        Standard:
          operations:
            pull_image:
              description: "Pull the image from source registry"
              implementation: scripts/pull_image.sh
              inputs:
                image_name: { get_property: [web_application, container_image] }

    # Destination Docker Registry
    destination_registry:
      type: tosca.nodes.Registry
      properties:
        name: "Destination Docker Registry"
        url: "https://destination-registry.com"
        credentials: 
          username: "dest_user"
          password: "dest_password"
      interfaces:
        Standard:
          operations:
            push_image:
              description: "Push the image to destination registry"
              implementation: scripts/push_image.sh
              inputs:
                image_name: { get_property: [web_application, container_image] }

    # Web Server
    web_server:
      type: tosca.nodes.Compute
      properties:
        os: "linux"
        instance_type: "t2.medium"
      interfaces:
        Standard:
          operations:
            configure:
              implementation: scripts/configure_web_server.sh

We can now define the logic for pulling the image from the source registry and pushing it to the destination registry in the pull_image.sh and push_image.sh scripts. These scripts can use tools like docker or skopeo to interact with the registries and move the images between them.

This extended TOSCA template allows us to define the entire deployment process, including moving the container image between registries, in a single declarative file. The orchestrator can then follow this template to deploy the application and manage the image transfer process automatically.

You can even extend this a little more:

Dedicated Image Transfer Node:

Instead of having the pull_image and push_image operations on the registries, we could define a dedicated node for transferring images between registries. This node would represent the transfer logic and could be scaled independently if needed.

Integrating with Helm:

If you're using Helm to manage Kubernetes deployments, you can integrate Helm hooks to trigger operations to validate the image transfer had been done before deploying a new version of the application. This way, you can ensure that the image is available in the destination registry before starting the deployment process.

SBOM Generation:

You could further enhance the template by adding SBOM generation after the image pull to capture and document all dependencies and vulnerabilities before moving to the destination registry.

By extending the TOSCA template with SBOM generation, you can ensure that your deployments are secure and compliant by tracking all dependencies and vulnerabilities in your container images.

SBOM: Tracking Dependencies and Vulnerabilities

While SBOMs (like CycloneDX or SPDX) aren't designed to manage orchestration, steps, or dependencies, they provide valuable metadata about software components, their licenses, and their relationships. SBOMs help with security, compliance, and tracking of software assets, but they don't handle deployment.

SBOMs, like CycloneDX and SPDX, provide a detailed inventory of components and vulnerabilities in software packages. They focus on the what—tracking all software components, their versions, dependencies, and potential security vulnerabilities. This transparency is crucial for managing risks and maintaining compliance in modern enterprise environments.

Extend SBOMs for Orchestration

Since SBOM focuses on describing the "what" (i.e., the components that make up an application or system), we can think of a way to extend SBOMs by adding "how" information to include dependencies and steps. Here's how we could theoretically extend SBOM for orchestration:

1. Component Description in SBOM:

   • Use existing SBOM structures to describe software components (e.g., web app, database, libraries).

   • Extend it by adding fields for deployment order and dependencies between components.

2. Define Relationships:

   • Introduce a new "orchestration" section in SBOM, similar to TOSCA's relationships or Docker Compose's depends_on. This section would define how different components rely on each other (e.g., app server depends on the database).

3. Deployment Steps:

   • Extend SBOMs to include execution scripts or commands for deploying components, similar to what CSAR or Docker Compose does with their create and run steps.

By doing this, SBOM could theoretically handle some orchestration tasks, though it's primarily designed for tracking components rather than deploying them.

Example of an Extended SBOM for airgap deployments:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "version": 1,
  "metadata": {
    "timestamp": "2024-10-28T12:34:56Z",
    "component": {
      "name": "MyWebApp",
      "version": "1.0",
      "type": "application"
    }
  },
  "components": [
    {
      "type": "container",
      "name": "webapp",
      "version": "1.0",
      "properties": [
        {
          "name": "image",
          "value": "myrepo/webapp:1.0"
        }
      ]
    },
    {
      "type": "platform",
      "name": "registries",
      "version": "1.0",
      "components": [
        {
          "type": "application",
          "name": "source_registry",
          "version": "1.0",
          "supplier": {
            "name": "docker hub",
            "url": [
              "https://source-registry.com"
            ]
          },
          "properties": [
            {
              "name": "username",
              "value": "myuser"
            },
            {
              "name": "password",
              "value": "mypassword"
            }
          ]
        },
        {
          "type": "application",
          "name": "destination_registry",
          "version": "1.0",
          "supplier": {
            "name": "quay.io",
            "url": [
              "https://destination-registry.com"
            ]
          },
          "properties": [
            {
              "name": "username",
              "value": "myuser"
            },
            {
              "name": "password",
              "value": "mypassword"
            }
          ]
        }
      ]
    }
  ],
  "externalReferences": [
    {
      "type": "formulation",
      "url": "https://orchestrator.com/wf/1234",
      "comment": "Workflow for deploying the web application"
    }
  ],
  "formulation": [ {
    "workflows": [
      {
        "taskTypes": ["deploy"],
        "uid": "0f8fad5b-d9cb-469f-a165-70867728950e",
        "bom-ref": "urn:k1s:webapp",
        "name": "deploy",
        "description": "Deploy the web application",
        "steps": [
          {
            "name": "pull",
            "description": "Pull the web application image",
            "commands": [
              {
                "executed": "pull",
                "properties": [
                  {
                    "name": "image",
                    "value": "myrepo/webapp:1.0"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }
  ],
  "dependencies": [
    {
      "ref": "webapp",
      "dependsOn": [
        "database"
      ]
    }
  ]
}

Here, the components are described as they normally would be in an SBOM. We've added a new "formulation" section to describe the deployment workflow, including steps like pulling the image from the source registry. The "dependencies" section specifies that the web application depends on the database component.

By extending SBOMs with orchestration information, we can create a more comprehensive view of software components and their deployment steps. This can help organizations manage complex deployments more effectively, especially in airgapped environments where transparency and control are critical.

Adding the Spices to Add Flavor to the Recipe: SABOR

The Proof Of Concept (POC) that I have in mind is to create a tool that can help you move images to private registries in airgapped environments. This tool will leverage the strengths of standard tools like CSAR and SBOM to provide a comprehensive solution for managing software packages in airgapped environments, as the catalog of images grows, the complexity of managing them increases, and the risk of security vulnerabilities grows. It will help you set up multiple private registries or environments, move images between them, and orchestrate deployments while tracking dependencies and vulnerabilities. See this as a tool that can help you to eliminate the burden of moving and packaging images in airgapped environments.

In your big enterprise projects, have you noticed that multiple teams or providers are duplicating the same work and breaking a standardization that could help to manage the software packages more efficiently? This tool will help you to centralize the work and make it easier to manage and update software packages.

How many images of the same software package do you have in your private registry? Commonly, in enterprise projects, you will have multiple images of the same software package in different "tenants" in the same registry, SABOR will help you to remove all the fat and keep only the necessary images, the perfect recipe!

Airflow in airgapped environments - secure, controlled, efficient

The starting point for SABOR is the SBOM. By leveraging the SBOM data, SABOR will provide a full breakdown of components while allowing users to securely package and distribute software without internet access. This is particularly vital for industries like telecom or defense, where security and compliance are paramount. Also, you can start from the bottom up, SABOR will help you generate the SBOM from the list of images that you define.

Demo: https://youtube.com/shorts/4ElqY-0Vtuc?feature=share

I decided to go with SBOM as the final solution because it provides a detailed inventory of components and vulnerabilities, making it easier to manage and update software packages. It also helps identify and manage vulnerabilities in software components, ensuring that organizations can address security risks proactively. SBOMs can be generated automatically as part of the software build process, ensuring that organizations have up-to-date information on software components. They can also be integrated with other tools and processes, such as vulnerability scanners and compliance tools, to provide a comprehensive view of software security and compliance.

By including orchestration metadata (like dependencies and deployment workflows) in the SBOM itself, you would allow users to not only track and verify components but also orchestrate them across multiple environments (public cloud, private cloud, and airgapped environments) securely and efficiently.

Conclusion

In this post, we explored the challenges of moving images to private registries in airgapped environments and discussed some of the alternatives available today. We looked at the strengths and limitations of CSAR and SBOM frameworks and how they could be extended to create a new approach to move images to private registries in airgapped environments. We also discussed the idea of combining the strengths of different tools and frameworks to create a comprehensive solution for managing software packages in airgapped environments.

What do you think about this approach? Do you think it could help solve the challenges of moving images to private registries in airgapped environments? I'd love to hear your thoughts and feedback on this idea!

Would you give it a try to SABOR? Let me know in the comments, and if you have any questions or suggestions, feel free to reach out. Go, Rebels! ✊🏼

Be curious, be rebellious, and keep learning! Subscribe to the newsletter for more content on Kubernetes, DevOps, and cloud-native technologies.