• 📝 Summary
• 🎤 Introduction
• 🛡️ Why not host Config files in Client Projects?
• 📁 Config files management and security
• 🗄️ File management
• 🔐 Security
• 👀 Can clients access VegaOps config files?
• ❌ If VegaOps subscription is cancelled?

📝 Summary

This document explains how VegaOps manages and secures Client Config Files.

1. VegaOps provides a private Git repository for each Client, which contains folders for each client project and only holds the associated pipeline configuration files.
2. VegaOps config files are accessible from the https://config.vegaops.com domain, and are secured with CF Zero Trust access.
3. Clients can review the pipeline config files from their GitLab Projects and download the Pipeline config files from their whitelisted VegaOps Main Servers.
4. At the time of cancellation of the subscription, VegaOps will provide a ZIP archive of the Client Config Git Repository, which will include the pipeline configuration files of all projects.
5. For any further details or queries, please contact your VegaOps Engineer or email [email protected] for assistance.

🤖 Note: The summary above has been generated by an AI engine (GPT-3). Please read through the entire document for more information.

🎤 Introduction

The VegaOps Team is responsible for managing DevOps Docker images, CI/CD pipeline configuration files, and keeping them up to date with latest fixes and improvements.

For infra setup information, please refer to the VegaOps Toolchain Architecture below:

VegaOps Toolchain Architecture

VegaOps Toolchain Architecture consists of the following components:

docs.peerxp.com

🛡️ Why not host Config files in Client Projects?

1. Trace and Rollback changes:
• If the VegaOps Config files were version-controlled in Client projects, they would be mixed with the Git history of the Application code, making it nearly impossible to roll back in most cases if any issues occur during pipeline setup or maintenance.
• The configuration file changes are tracked and version-controlled in our private Client Config Git Repositories, enabling us to quickly trace and roll back changes if any issues arise.
2. Change propagation:
• Due to the nature of Git repositories, if a Config file is hosted in a Client project and an Engineer requires any changes to be made to it in the main branch, it may take a few days to a few weeks for the update to become visible in all the repository's branches.
• The changes will not be applied until all other repository branches have merged the new changes from the main branch. Until then, they will continue using an older version of the Config file, which can lead to unreliable or broken pipelines.
• However, when the Config file is loaded remotely and an Engineer makes changes to address any requirements, those changes are applied instantly across all Git branches of a Project, taking effect immediately.
3. Fixing deprecations and making improvements:
• GitLab CE releases regular updates to the CI/CD YAML syntax and associated GitLab APIs used in pipelines on the 22nd of every month. Similarly, pipeline and Docker image dependencies may become broken due to changes that are out of our control.
• At VegaOps, we have automated systems that enable our team to modify YAML files quickly and effectively, addressing any deprecations and optimizing pipeline code to take advantage of new developments. We carry out this process for more than 2000 client projects monthly.
• These changes are applied to all projects as part of a Canary release, taking immediate effect to ensure no project encounters any pipeline issues due to external dependencies.
4. Security:
• If configuration for the CI/CD pipeline is present in the application code, interns (or even malicious actors) could unintentionally or deliberately make changes to the YAML files that could break the entire production pipeline.
• Config files often contain sensitive information related to the pipeline design, and should only be accessed by authorized personnel.
• Therefore, it is a standard security procedure for companies to store pipeline configurations outside of their application repositories, with restricted access.

📁 Config files management and security

Below is a summary of the guidelines and security practices employed by the VegaOps team to ensure the reliability and safety of our Client's CI/CD systems.

🗄️ File management

1. We dedicate a private Git repository to each Client within our private GitLab instance. These client-specific repositories contain folders for each client project, which only hold the associated pipeline configuration files.
2. Any modification to a Config file triggers a pipeline that deploys and applies changes to a High-Availability AWS instance deployed across multiple Availability Zones.
3. VegaOps config files are accessible from the https://config.vegaops.com domain (in the Production environment) and https://stg-config.vegaops.com (in the Staging environment).
4. In the Client Git repositories, the pipeline config files are loaded from the https://config.vegaops.com domain (Production environment).

🔐 Security

1. The Client Config Git repositories are only accessible to authorized VegaOps Team members, and all changes must be committed with cryptographically signed commits.
2. VegaOps Config AWS instances are secured with CF Zero Trust access (Identify + Device Posture), providing limited and privileged access only to authorized users.
3. Additionally, automated backups are configured for the Config Git repositories, as well as the AWS instance data. The backups are stored across multiple cloud providers and regions.
4. Access to the Config files (https://config.vegaops.com domain) is only permitted to the IP addresses of Client instances on which the VegaOps Main Server is installed.

👀 Can clients access VegaOps config files?

✅ Absolutely!

1. Review Config Files: You can review the contents of any GitLab project's pipeline configuration by navigating to your private GitLab instance's Project page → CI/CD → Editor → View the merged YAML file.
2. Download Config files: You can download the Pipeline Config files for any Project using the remote link (starts with https://config.vegaops.com) available in the .vegaops-glci.yml file of your project. Make sure to download these files from your whitelisted VegaOps Main Server.
3. Docker images: The latest version of all Docker images used in pipelines are accessible locally in the VegaOps Runner Servers.

❌ If VegaOps subscription is cancelled?

Our team is committed to providing a hassle-free experience and top-notch service, helping you with all your DevSecOps needs and ensuring your DevOps systems are always running smoothly.

We understand the importance of having reliable systems, so we take the necessary steps to ensure their reliable operation with minimal manual intervention and reducing the risk of human errors.

However, at any point you feel that our services are not meeting your needs, please do not hesitate to reach out to our team and we will make sure to address your concerns.

At the time of cancellation of the subscription, there is no lock-in whatsoever; the VegaOps team will provide a ZIP archive of the Client Config Git Repository hosted by us, which will include the pipeline configuration files of all your projects. 🙇

For any further details or queries, please contact your VegaOps Engineer or email [email protected] for assistance.