Separate environment for the Security department for:
This enclave will contain at minimum:
liveenvironment suitable for processing and storing RED data.
integrationenvironment with scaled down architecture for testing integrations.
All environments will follow compliance and retention requirements.
When discussing the Security Enclave:
liveto avoid ambiguity with other environments.
@gitlabsec.netin user and group names.
projectis unfortunately an overloaded term between GCP and GitLab, so specify as "GCP Project" or "GitLab project" when necessary.
Follow best practices to ensure that artifacts deployed to the environment are available in local mirrors or caches. Use available tools to verify the integrity of artifacts deployed to the environment.
Rely on high avaialibility services when necessary or otherwise determined that the risk is acceptable.
GitLab features such as container scanning and private docker registries can be used to shift security left for this environment.
Many of the workloads for the proposed systems can be deployed as kubernetes workloads, with the advantages of shifting our own security left and making use of GitLab features such as container scanning and private registries.
The Security enclave will contain a maintained GitLab instance for the following work:
Container registry and scanning for the kubernetes workloads deployed to the environments.
CI for terraform deployments will be run in
live GitLab, using private runners
within the environment. This means that some maintenance of the
instance and the runners can not be done through CI, but can still be tracked
in terraform and executed manually.
Issue on the tracking for non-public by default issues CI for working with customer data (RED) from GitLab.com Application Resources
Access to GCP resources using IAM using Google Groups for groups specified in the Role Entitlements listed below. This is to maintain independence from other corporate systems
To effectively use Google groups for access control lists:
Group Administratorin G Suite.
While other technologies will be evaluated for maintainablity and cost, preference will be given to GCP native tooling where it exists.
A new top-level domain
gitlabsec.net will be used for resources related to the Security Enclave
to reduce the interaction between systems due to the behavior of integrations
such as email for SaaS application being routed through G Suite.
Cloud DNS will be used to manage records for the domain. Similar to the other independent resources, Cloud DNS will not have the same dependencies as other DNS providers used in production for GitLab.com.
An automated process and tooling should be implemented where possible to ensure that records are kept up to date with resources. Where not possible, change control tracking processes should include steps for admins to review for associated resources when modifying or removing resources.
Some shared resources that will need to be maintained for uptime, but not
necessarily have duplicated
integration resources associated with them:
The following workloads will be implemented in both
Bootstrapping the environment may need to be performed by running various terraform and chef provisioning steps manually until the GitLab instance is sufficiently configured to perform these tasks via CI.
We will be relying on auto-scaling and multi-zone failover using GCP load balancers for the Kubernetes workloads. We will be relying on CloudSQL for any workload that supports it as a database (GitLab).
The following workloads will have ready instances in a second zone (pods or VMs as necessary):
We will be relying on monitoring and the queuing features of pubsub to reliably ingest data into DELKE.
Other workloads, such as MISP, may be useful but not required during operations at this time, so do not require additional measures other than monitoring and detection to meet HA needs.
We will scheuld CloudSQL backups via terraform, with multi-region storage for backup.
All repositories used for the maintenance of the Security Enclave will push mirrored to GitLab.com or ops.gitlab.net.
This role is defined in addition to job title/function for individuals whose work requires additional access in addition to their job function granted roles. The need for this role should be minimized to maintain least privilege.
security-integration: An empty, scaled down environment with no real data for testing integration between various systems, e.g. Cloud Functions that access the hive.
backup: Project to hold copies of backups
gitlab-security project in GCP can continue to be used for POCs,
As part of this process, it will be audited for data and access restrictions.
Applications currently using the
gitlab-security AWS project will be migrated
off to reduce the resource footprint of Security department initiatives.