[Parent Epic] Vendor IAC
Problem Statement
Platform One mandates that all supported Kubernetes distribution contain IAC on repo1. However, there is currently no way to validate that the provided IAC is functioning within the various constraints of P1 and its customers. On the other side of the coin, there is no formal mechanism for Big Bang to validate a deployment against vendor provided IAC and inform customers.
This not only creates confusion amongst current and potential Platform One customers on which distros Big Bang is supported on, but also lacks transparency for vendors looking to submit and validate IAC on repo1.
Ultimately, Big Bang is designed to run without limitation on any CNCF compliant Kubernetes distribution. To validate that claim, we need to be repeatably testing against the various distributions.
Proposal
Build a pluggable CI framework to test vendor IAC and Big Bang deployments. Ensure framework is flexible enough for vendors to provide their IAC within certain P1/BB provided constraints.
- Big Bang to provide a pluggable framework for vendors to test their IAC
- P1 validates that vendor-provided IAC is compatible for each BB release via CI/CD which consumes respective vendor repos in a sandbox environment
- Vendor IAC will be published to this repository
Constraints
- Currently Big Bang can only be tested on AWS and does not have a way forward for other K8s cloud distros (i.e. AKS, GKE, etc.)
- It is the vendor's sole responsibility to ensure IAC is functioning within the constraints of the provided pluggable framework.
- Given the P1 pluggable framework, vendors are responsible for:
- deploying / testing BB in their own environment
- contributing working IAC to the repo1.dso.mil/platform-one/distros
- opening repo1.dso.mil/platform-one/big-bang issues to resolve discrepancies related to the BB product
Activity
added epiccandidate label
added epic &38 (closed) as parent epic
first pass at defining known pre-requisites for ocp and rke2 are in this MR
added sizelarge label
removed sizelarge label
added sizexl label
green is what is done today
graph LR A[In Cluster Smoke Tests] --> AWS_NU(AWS Network Up) A --> AZURE_NU(Azure Network Up) A --> ETC(etc...) subgraph AWS AWS_NU --> AWS_CU_RKE2(AWS RKE2 Cluster Up) AWS_CU_RKE2 --> AWS_BBU_RKE2(AWS RKE2 BigBang Up) AWS_BBU_RKE2 --> AWS_BB_E2E_RKE2(AWS RKE2 BigBang E2E) AWS_BB_E2E_RKE2 --> AWS_BBD_RKE2(AWS RKE2 BigBang Down) AWS_BBD_RKE2 --> AWS_CD_RKE2(AWS RKE2 Down) AWS_CD_RKE2 --> AWS_ND(AWS Network Down) AWS_NU --> AWS_CU_AG_RKE2(AWS Airgap RKE2 Cluster Up) AWS_CU_AG_RKE2 --> AWS_BBU_AG(AWS Airgap BigBang Up) AWS_BBU_AG --> AWS_BB_E2E_AG(AWS Airgap BB E2E) AWS_BB_E2E_AG --> AWS_BBD_AG(AWS Airgap BigBang Down) AWS_BBD_AG --> AWS_CD_AG_RKE2(AWS Airgap RKE2 Cluster Down) AWS_CD_AG_RKE2 --> AWS_ND AWS_NU --> AWS_CU_EKS(AWS EKS Cluster Up) AWS_CU_EKS --> AWS_BBU_EKS(AWS EKS Cluster Up) AWS_BBU_EKS --> AWS_BB_E2E_EKS(AWS EKS BigBang E2E) AWS_BB_E2E_EKS --> AWS_BBD_EKS(AWS EKS BigBang Down) AWS_BBD_EKS --> AWS_CD_EKS(AWS EKS Cluster Down) AWS_CD_EKS --> AWS_ND end subgraph Azure AZURE_NU --> AZURE_CU_AKS(Azure AKS Cluster Up) AZURE_CU_AKS --> AZURE_ETC(etc...) end style AWS_NU fill:#00ff00 style AWS_CU_RKE2 fill:#00ff00 style AWS_BBU_RKE2 fill:#00ff00 style AWS_BB_E2E_RKE2 fill:#00ff00 style AWS_BBD_RKE2 fill:#00ff00 style AWS_CD_RKE2 fill:#00ff00 style AWS_ND fill:#00ff00
goals:
- validate bigbang on p1 approved distros in each of the primary operating environments (C1D, C2S, etc...)
- expand BB's E2E suite to increase confidence in deployments via automated tests
- provide bigbang stamp of approvals for the combination of a distro + operating environment
not goals:
- test all customer driven operating environments (this is prohibitively expensive)
- test on real environments (mock out the security posture of each environment as much as possible, each CI run should be on completely new infra)
- advertising page for vendors, bigbang is solely concerned with a single, bigbang stamp of approval
nice to haves:
- additional environment scans (oscap stig scan on distro provided OS)
- ???
Edited by joshwolfadded priority7 label
This story from the Integration team may be related to this epic: https://jira.il2.dso.mil/browse/BBOI-1110
added epic &162 (closed) as parent epic
@gabe can we re-evaluate what we want on this and how we want to go about it? Josh's description is 1 year old and i think it needs updating...
@ryan.thompson.44 adding you since gabe is going to be out for a while
The desire would be to have a single pipeline, that has a hook for the different Kubernetes distribution that would be in Iron Bank. The pipeline would pull a Kubernetes distribution, spin it up, deploy Big Bang on it, and tear it down before moving to the next distribution.
Following the deployment, it would complete a "Compatibility Check" to see if the Kubernetes distribution version and the Big Bang version are "Compatible" and provides a report view like https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/Packages.md showing "compatible" or "not compatible".
This likely would be a Big Bang Release pipeline rather than run for every commit.
Additionally, with standardized hooks for the different Kubernetes distributions, it may be possible to have the vendors help maintain that code for each new distribution version.
Thoughts?
Edited by Ryan Thompson
added epiclater teamci/pipelines labels
removed parent epic &162 (closed)
added epic &70 (closed) as child epic
added epic &162 (closed) as child epic
removed epiccandidate label
added issue bigbang#1311
mentioned in issue bigbang#1312
moved child epic platform-one/big-bang/pipeline-templates&1 to epic &2 (closed)
marked this epic as related to &247 (closed)
added epicparent label and removed epiclater label