New GitGuardian Architecture

Beginning with version 2023.6.0 for Helm-based and 2023.11.0 for KOTS-based installations, there are notable changes in the deployment architecture of the GitGuardian application.

The new GitGuardian application now features a brand new cloud architecture, representing a shift from the previous deployment setup, hereby referred to as GitGuardian Legacy.

As of now, the new GitGuardian architecture is implemented for all new installations. Moving forward, we strongly encourage users currently on the GitGuardian Legacy architecture to consider migrating to the new architecture. The transition not only brings numerous improvements but also ensures your system benefits from the latest security, performance, and scalability enhancements that GitGuardian has to offer.

info

To facilitate this migration, we have outlined a comprehensive migration guide, which can be found here.

The legacy version will be deprecated on November 1st, 2024 for embedded cluster installations and on January 1st, 2025 for existing cluster installations. After these dates, all new releases will be exclusively for the new architecture, and no further updates will be made to the legacy version.

GitGuardian's new application is moving away from the KOTS templates used in GitGuardian Legacy and is now using Helm chart. You now have the flexibility to deploy the application either through the KOTS admin interface UI (KOTS-based) or directly via a Helm CLI (Helm-based).

How do I know if I am using the New or Legacy GitGuardian architecture?

When installing the GitGuardian application, the method of installation will correlate with the architecture you are using.

• For installations done via Helm, you are automatically using the new GitGuardian architecture.

• For KOTS installations, you can differentiate between the Legacy and the new GitGuardian architecture by examining the URL of your KOTS Admin Console.

  For instance:

  • A URL ending with /gitguardian-seal signifies the Legacy architecture, as seen in https://example.gitguardian.com:8800/app/gitguardian-seal.
  • A URL ending with /gitguardian indicates the new architecture of the application, exemplified by https://example.gitguardian.com:8800/app/gitguardian.

What's new in the GitGuardian application

Explore the array of enhancements introduced with the new GitGuardian architecture below:

A more scalable architecture

While GitGuardian Legacy proposes a simple yet robust architecture, the new GitGuardian architecture is more flexible and can better scale for high workloads.

The new GitGuardian flexible architecture deploys a service for each key component of the application enhancing scalability. These services can each be independently scaled and tuned:

• Adjustment of replica counts,
• Configuring requests and limits (Helm Install lets you set them all, while KOTS-based install has some restrictions),
• Creation of dedicated workers to handle high-demand queues (Helm only)

For detailed insights into deployment/pod names, types, and their usage, visit the GitGuardian Application Topology page. For guidelines on scaling GitGuardian, refer to Scaling GitGuardian.

Support of Helm Command Line

Introduced in 2023.6.0, the helm install feature has been incorporated into the GitGuardian application, promoting the adoption of the industry-standard Helm package manager for streamlined installation and upgrade processes.

This integration enables configuration as code, and in future releases, we plan to extend support for GitOps tools like ArgoCD, along with advanced configuration options such as External Secrets Operator, Istio Service Mesh & Gateway, and Certificate Manager.

Explore: Install on an Existing cluster using Helm.

Simplified Storage for Embedded Installations

We have streamlined the installation process for embedded clusters by eliminating the need for an additional block storage device. This enhancement not only simplifies setups and POCs but also reduces the infrastructure overhead compared to the GitGuardian Legacy version, which required two separate disks.

Explore: Install on an Embedded cluster.

TLS Certificates Simplified

TLS certificates used for KOTS Admin Console and GitGuardian application can be now the same, simplifying the installation.

Moreover, instead of being mounted in the NGINX containers, the certificate is now installed on a Kubernetes ingress object. This change simplifies certificate lifecycle management and eliminates the need to restart the container for updating the certificate, as was necessary in the legacy application.

Read More: TLS certificates documentation.

Default Ingress

In the new GitGuardian application, the default ingress is now customizable, allowing modifications to className, pathType, TLS, Annotations/Labels. This is a shift from the GitGuardian Legacy where a preset default ingress was provided.

Read More: Ingress documentation.

info

Customers always have the flexibility to employ their own ingress and have the option to disable the default ingress if preferred.

Enhanced Security with Chainguard Integration

The new GitGuardian architecture now integrates Chainguard, a cutting-edge security tool that significantly lowers the risk of Common Vulnerabilities and Exposures (CVEs) in self-hosted images.

This integration not only fortifies our container images against vulnerabilities but also brings in FIPS-approved cryptographic modules, ensuring robust encryption of sensitive data both at rest and in transit. With Chainguard, GitGuardian sets a new standard in security, ensuring our architecture adheres to the highest compliance and security benchmarks.

Read More: Common Vulnerabilities and Exposures.

Cosign for image signing

Starting with the 2024.3.0 release in the new architecture, GitGuardian has adopted Cosign for enhanced image security, aligning with SLSA 2 standards. This integration ensures the integrity and authenticity of our container images through robust signing and verification processes. By leveraging Cosign, part of the Sigstore project, GitGuardian not only strengthens its security posture but also assures users of the trustworthiness of our software distribution. This move underscores our commitment to implementing advanced security solutions for our users' peace of mind.

Read More: Cosign for image signing.

Was this page helpful?