|
|
# Roadmap
|
|
|
|
|
|
This wiki page looks to outline long term items that should/could be tackled by Big Bang
|
|
|
|
|
|
## Pipelines as Product
|
|
|
|
|
|
The biggest blocker to setting up a software factory is the time it takes to install and configure pipelines within Gitlab to function correctly.
|
|
|
|
|
|
## SPIFFE-SPIRE
|
|
|
|
|
|
## SLSA Framework
|
|
|
|
|
|
This could be grouped under Pipelines as Product, but this talks more about ensuring the right tools are available to provide pipelines that could meet SLSA Level 2/3 compliance
|
|
|
|
|
|
## VAT Alternative
|
|
|
|
|
|
The VAT is an internal P1 tool used to perform vulnerability justification and acceptance. This works well for the P1 team on Ironbank, but end users of BigBang do not have a comparable tool that can be used in their environment.
|
|
|
|
|
|
- https://dependencytrack.org/
|
|
|
- https://nucleussec.com/
|
|
|
|
|
|
|
|
|
## Serverless
|
|
|
|
|
|
Serverless frameworks provide multiple benefits long term:
|
|
|
|
|
|
* Resource utilization - by spinning down pods to 0 when not being used, resource usage by applications can be reduced long term.
|
|
|
|
|
|
* Standardizing mission applications - Current workflow for adding Mission Apps to a cluster is to create manifests for each application that comply with the policies defined by Kyverno and Gatekeeper. By using a framework like Knative, the sysadmins can define the standard template for spinning up pods that would translate the CRD:
|
|
|
|
|
|
```yaml
|
|
|
apiVersion: serving.knative.dev/v1
|
|
|
kind: Service
|
|
|
metadata:
|
|
|
name: helloworld-go
|
|
|
namespace: default
|
|
|
spec:
|
|
|
template:
|
|
|
spec:
|
|
|
containers:
|
|
|
- image: ghcr.io/stefanprodan/podinfo:6.1.0
|
|
|
ports:
|
|
|
- containerPort: 9898
|
|
|
env:
|
|
|
- name: PODINFO_UI_COLOR
|
|
|
value: "#34577c"
|
|
|
```
|
|
|
into multiple objects that have the correctly configured `Deployments`, `Services`, `VirtualServices`, etc. |
|
|
\ No newline at end of file |