Git Connector provides easy integration for centralized configuration management and Git repositories.

With the rise of Kubernetes and DevOps, GitOps also gains more traction. In short, the goal of GitOps is:

• Infrastructure as Code (a Git repository is the single point of truth)
• The Git repository represents the desired state of the application
• A change to the Git repository leads to a redeployment so the application is deployed as defined in the Git repository

How does this concept of a Git repository as a single point of truth fit together with the ConfigSeeder® approach of managing configuration data in a central location?

Integration of ConfigSeeder & Git

The answer to this question is the ConfigSeeder extension Git Connector. This extension is able to:

• For any number of Git repositories & Branches
• Retrieve configuration data from ConfigSeeder
• Push configuration data in form of files to the Git repository
• Form a bridge between ConfigSeeder and one or many Git repositories

The following image gives an overview of the Git Connector:

The use of the Git Connector must be licensed. Don’t hesitate to contact us if you like to do a proof of concept and retrieve the Docker Image from docker hub.

Benefits of the Git Connector

Support GitOps but preserve the benefits of centralized configuration management

For the DevOps Tool, the Git repository is the single point of truth. It doesn’t matter that in the background the data stored in the Git repository is managed by ConfigSeeder. And from an Application Manager / Release Manager / Developer point of view, ConfigSeeder is still the one place to manage configuration data at a centralized location (with all the other benefits coming with ConfigSeeder).

Low coupling between applications and ConfigSeeder®

With the use of the Git Connector, from an application (or DevOps) point of view, the source of configuration data is the Git repository. There is no direct dependency on ConfigSeeder.

Support of Sealed Secrets

GitOps tools like ArgoCD can be used to provision Helm Charts to a Kubernetes Cluster. Most Helm Charts need at least one Secret. However, Kubernetes Secrets are not really protected and therefore shouldn’t be stored in a Git repository. That’s where Sealed Secrets come into play. They contain sensitive data – but in an encrypted form. Sealed Secrets therefore can be stored in a Git repository without hesitation.

However, working with Sealed Secrets is cumbersome: Once a Sealed Secret is created, a developer usually can’t look into the values stored in the Sealed Secret (this is one of the goals of Sealed Secrets). If a Sealed Secret holds more than one value, all values must be known to create a new version.

ConfigSeeders® Git Connector removes this pain point. Just activate Git Connectors Sealed Secret support, point it to the right certificates and it will convert all Kubernetes Secrets to be stored in a Git repository automatically to Sealed Secrets.

Supported object

The Git Connector can push the following objects to Git:

• Files with static content
• Files with templated content
• ConfigMaps containing Key/Value pairs or templated content
• Secrets containing Key/Value pairs, Image Pull Secrets and Secrets containing a Keystore
• Optionally, Secrets can be converted to Sealed Secrets before storing them in Git

Next Steps

Don’t hesitate to contact us if you have any questions or if you need a trial license.