diff --git a/.gitlab/README.md.gotmpl b/.gitlab/README.md.gotmpl
deleted file mode 100644
index 268007fbfc2a93db2d1ba7a5728ce7ae68c84bb9..0000000000000000000000000000000000000000
--- a/.gitlab/README.md.gotmpl
+++ /dev/null
@@ -1,34 +0,0 @@
-{{ template "chart.header" . }}
-{{ template "chart.deprecationWarning" . }}
-
-{{ template "chart.badgesSection" . }}
-
-{{ template "chart.description" . }}
-
-{{ template "chart.homepageLine" . }}
-
-> _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/). Please direct all code changes, issues and comments to https://repo1.dso.mil/platform-one/big-bang/bigbang_
-
-Big Bang follows a [GitOps](#gitops) approach to configuration management, using [Flux v2](#flux-v2) to reconcile Git with the cluster. Environments (e.g. dev, prod) and packages (e.g. istio) can be fully configured to suit the deployment needs.
-
-## Usage
-
-Big Bang is intended to be used for deploying and maintaining a DoD hardened and approved set of packages into a Kubernetes cluster. Deployment and configuration of ingress/egress, load balancing, policy auditing, logging, monitoring, etc. are handled via Big Bang. Additional packages (e.g. ArgoCD, GitLab) can also be enabled and customized to extend Big Bang's baseline. Once deployed, the customer can use the Kubernetes cluster to add mission specific applications.
-
-Additional information can be found in [Big Bang Docs](./docs/README.md).
-
-## Getting Started
-
-To start using Big Bang, you will need to create your own Big Bang environment tailored to your needs. The [Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.
-
-{{ template "chart.maintainersSection" . }}
-
-{{ template "chart.sourcesSection" . }}
-
-{{ template "chart.requirementsSection" . }}
-
-{{ template "chart.valuesSection" . }}
-
-## Contributing
-
-Please see the [contributing guide](./CONTRIBUTING.md) if you are interested in contributing to Big Bang.
diff --git a/.gitlab/base_config.md.gotmpl b/.gitlab/base_config.md.gotmpl
new file mode 100644
index 0000000000000000000000000000000000000000..0148cfdecd23772bc4ab337933432ea34588a07e
--- /dev/null
+++ b/.gitlab/base_config.md.gotmpl
@@ -0,0 +1,18 @@
+{{ template "chart.header" . }}
+{{ template "chart.deprecationWarning" . }}
+
+{{ template "chart.badgesSection" . }}
+
+{{ template "chart.description" . }}
+
+## Getting Started
+
+To start using Big Bang, you will need to create your own Big Bang environment tailored to your needs. The [Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.
+
+{{ template "chart.maintainersSection" . }}
+
+{{ template "chart.sourcesSection" . }}
+
+{{ template "chart.requirementsSection" . }}
+
+{{ template "chart.valuesSection" . }}
diff --git a/README.md b/README.md
index f45a0ddcba820b99711f37cf0a0132afe436caac..9dde8d8896bc7d8fcd780b9d50f4806618b42205 100644
--- a/README.md
+++ b/README.md
@@ -1,457 +1,45 @@
-# bigbang
+# Big Bang
- 
+Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster.
-Big Bang is a declarative, continuous delivery tool for core DoD hardened and approved packages into a Kubernetes cluster.
+## Usage & Scope
-**Homepage:** <https://p1.dso.mil/#/products/big-bang>
+Big Bang's scope is to provide publicly available installation manifests for:
-> _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/). Please direct all code changes, issues and comments to https://repo1.dso.mil/platform-one/big-bang/bigbang_
+- A specific set of packages that adhere to the DevSecOps Reference Architecture. The core list of packages can be found [here](https://repo1.dso.mil/platform-one/big-bang/apps/core).
-Big Bang follows a [GitOps](#gitops) approach to configuration management, using [Flux v2](#flux-v2) to reconcile Git with the cluster. Environments (e.g. dev, prod) and packages (e.g. istio) can be fully configured to suit the deployment needs.
+- Packages that facilitate development of applications that adhere to the DevSecOps Reference Architecture. The full list of packages can be found [here](https://repo1.dso.mil/platform-one/big-bang/apps).
-## Usage
+Big Bang also builds tooling around the testing and validation of Big Bang packages. These tools are provided as-is, without support.
Big Bang is intended to be used for deploying and maintaining a DoD hardened and approved set of packages into a Kubernetes cluster. Deployment and configuration of ingress/egress, load balancing, policy auditing, logging, monitoring, etc. are handled via Big Bang. Additional packages (e.g. ArgoCD, GitLab) can also be enabled and customized to extend Big Bang's baseline. Once deployed, the customer can use the Kubernetes cluster to add mission specific applications.
Additional information can be found in [Big Bang Docs](./docs/README.md).
-## Getting Started
-
-To start using Big Bang, you will need to create your own Big Bang environment tailored to your needs. The [Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.
-## Maintainers
+## Getting Started
-| Name | Email | Url |
-| ---- | ------ | --- |
-| Ryan Garcia | garcia.ryan@solute.us | |
-| Michael McLeroy | michaelmcleroy@cloudfitsoftware.com | |
-| Micah Nagel | micah.nagel@parsons.com | |
-| Branden Cobb | cobb_branden@bah.com | |
-| Tom Runyon | tom@defenseunicorns.com | |
+- You will need to instantiate a Big Bang environment tailored to your needs. [The Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.
-## Source Code
+## Contributing to Big Bang
-* <https://repo1.dso.mil/platform-one/big-bang/bigbang>
+There are 3 main ways to contribute to Big Bang:
+- [Submit new package proposals](https://repo1.dso.mil/platform-one/bbtoc/-/issues/new?issue%5Bmilestone_id%5D=)
+ - Please review the [package integration guide](/docs/developer/package-integration.md) if you are interested in submitting a new package
+ - A shepherd will be assigned to the project to create a repo in the [BB sandbox](https://repo1.dso.mil/platform-one/big-bang/apps/sandbox)
+- [Contribute to open-source projects under the Big Bang Technical Oversight Committee (bbtoc)](https://repo1.dso.mil/platform-one/bbtoc/-/blob/master/CONTRIBUTING.md)
+- [Contribute to the Big Bang Team's Backlog](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/issues)
-## Values
+## Release Schedule
+- Big Bang releases every 2 weeks. In order to stay current with all features and security updates ensure you are no more than `n-2` releases behind.
+ - To see what is on the roadmap please see our [project milestones](https://repo1.dso.mil/groups/platform-one/big-bang/-/milestones)
-| Key | Type | Default | Description |
-|-----|------|---------|-------------|
-| domain | string | `"bigbang.dev"` | Domain used for BigBang created exposed services, can be overridden by individual packages. |
-| offline | bool | `false` | (experimental) Toggle sourcing from external repos. All this does right now is toggle GitRepositories, it is _not_ fully functional |
-| registryCredentials | object | `{"email":"","password":"","registry":"registry1.dso.mil","username":""}` | Single set of registry credentials used to pull all images deployed by BigBang. |
-| openshift | bool | `false` | Multiple sets of registry credentials used to pull all images deployed by BigBang. Credentials will only be created when a valid combination exists, registry, username, and password (email is optional) Or a list of registires: - registry: registry1.dso.mil username: "" password: "" email: "" - registry: registry.dso.mil username: "" password: "" email: "" Openshift Container Platform Feature Toggle |
-| git | object | `{"credentials":{"caFile":"","knownHosts":"","password":"","privateKey":"","publicKey":"","username":""},"existingSecret":""}` | Git credential settings for accessing private repositories Order of precedence is: 1. existingSecret 2. http credentials (username/password/caFile) 3. ssh credentials (privateKey/publicKey/knownHosts) |
-| git.existingSecret | string | `""` | Existing secret to use for git credentials, must be in the appropriate format: https://toolkit.fluxcd.io/components/source/gitrepositories/#https-authentication |
-| git.credentials | object | `{"caFile":"","knownHosts":"","password":"","privateKey":"","publicKey":"","username":""}` | Chart created secrets with user defined values |
-| git.credentials.username | string | `""` | HTTP git credentials, both username and password must be provided |
-| git.credentials.caFile | string | `""` | HTTPS certificate authority file. Required for any repo with a self signed certificate |
-| git.credentials.privateKey | string | `""` | SSH git credentials, privateKey, publicKey, and knownHosts must be provided |
-| sso | object | `{"auth_url":"https://{{ .Values.sso.oidc.host }}/auth/realms/{{ .Values.sso.oidc.realm }}/protocol/openid-connect/auth","certificate_authority":"","client_id":"","client_secret":"","jwks":"","oidc":{"host":"login.dso.mil","realm":"baby-yoda"},"secretName":"tls-ca-sso","token_url":"https://{{ .Values.sso.oidc.host }}/auth/realms/{{ .Values.sso.oidc.realm }}/protocol/openid-connect/token"}` | Global SSO values used for BigBang deployments when sso is enabled, can be overridden by individual packages. |
-| sso.oidc.host | string | `"login.dso.mil"` | Domain for keycloak used for configuring SSO |
-| sso.oidc.realm | string | `"baby-yoda"` | Keycloak realm containing clients |
-| sso.certificate_authority | string | `""` | Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see docs/assets/configs/example/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages |
-| sso.jwks | string | `""` | Keycloak realm's json web key output, obtained at https://<keycloak-server>/auth/realms/<realm>/protocol/openid-connect/certs |
-| sso.client_id | string | `""` | OIDC client ID used for packages authenticated through authservice |
-| sso.client_secret | string | `""` | OIDC client secret used for packages authenticated through authservice |
-| sso.token_url | string | `"https://{{ .Values.sso.oidc.host }}/auth/realms/{{ .Values.sso.oidc.realm }}/protocol/openid-connect/token"` | OIDC token URL template string (to be used as default) |
-| sso.auth_url | string | `"https://{{ .Values.sso.oidc.host }}/auth/realms/{{ .Values.sso.oidc.realm }}/protocol/openid-connect/auth"` | OIDC auth URL template string (to be used as default) |
-| sso.secretName | string | `"tls-ca-sso"` | Kubernetes Secret containing the sso.certificate_authority value for SSO enabled application namespaces |
-| flux | object | `{"install":{"remediation":{"retries":-1}},"interval":"2m","rollback":{"cleanupOnFail":true,"timeout":"10m"},"test":{"enable":false},"timeout":"10m","upgrade":{"cleanupOnFail":true,"remediation":{"remediateLastFailure":true,"retries":3}}}` | (Advanced) Flux reconciliation parameters. The default values provided will be sufficient for the majority of workloads. |
-| networkPolicies | object | `{"controlPlaneCidr":"0.0.0.0/0","enabled":true,"nodeCidr":"","vpcCidr":"0.0.0.0/0"}` | Global NetworkPolicies settings |
-| networkPolicies.enabled | bool | `true` | Toggle all package NetworkPolicies, can disable specific packages with `package.values.networkPolicies.enabled` |
-| networkPolicies.controlPlaneCidr | string | `"0.0.0.0/0"` | Control Plane CIDR, defaults to 0.0.0.0/0, use `kubectl get endpoints -n default kubernetes` to get the CIDR range needed for your cluster Must be an IP CIDR range (x.x.x.x/x - ideally with /32 for the specific IP of a single endpoint, broader range for multiple masters/endpoints) Used by package NetworkPolicies to allow Kube API access |
-| networkPolicies.nodeCidr | string | `""` | Node CIDR, defaults to allowing "10.0.0.0/8" "172.16.0.0/12" "192.168.0.0/16" "100.64.0.0/10" networks. use `kubectl get nodes -owide` and review the `INTERNAL-IP` column to derive CIDR range. Must be an IP CIDR range (x.x.x.x/x - ideally a /16 or /24 to include multiple IPs) |
-| networkPolicies.vpcCidr | string | `"0.0.0.0/0"` | VPC CIDR, defaults to 0.0.0.0/0 In a production environment, it is recommended to setup a Private Endpoint for your AWS services like KMS or S3. Please review https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html to setup routing to AWS services that never leave the AWS network. Once created update `networkPolicies.vpcCidr` to match the CIDR of your VPC so Vault will be able to reach your VPCs DNS and new KMS endpoint. |
-| imagePullPolicy | string | `"IfNotPresent"` | Global ImagePullPolicy value for all packages Permitted values are: None, Always, IfNotPresent |
-| istio.enabled | bool | `true` | Toggle deployment of Istio. |
-| istio.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-controlplane.git"` | |
-| istio.git.path | string | `"./chart"` | |
-| istio.git.tag | string | `"1.13.5-bb.2"` | |
-| istio.enterprise | bool | `false` | Tetrate Istio Distribution - Tetrate provides FIPs verified Istio and Envoy software and support, validated through the FIPs Boring Crypto module. Find out more from Tetrate - https://www.tetrate.io/tetrate-istio-subscription |
-| istio.ingressGateways.public-ingressgateway.type | string | `"LoadBalancer"` | |
-| istio.ingressGateways.public-ingressgateway.kubernetesResourceSpec | object | `{}` | |
-| istio.gateways.public.ingressGateway | string | `"public-ingressgateway"` | |
-| istio.gateways.public.hosts[0] | string | `"*.{{ .Values.domain }}"` | |
-| istio.gateways.public.autoHttpRedirect | object | `{"enabled":true}` | Controls default HTTP/8080 server entry with HTTP to HTTPS Redirect. |
-| istio.gateways.public.tls.key | string | `""` | |
-| istio.gateways.public.tls.cert | string | `""` | |
-| istio.flux | object | `{}` | Flux reconciliation overrides specifically for the Istio Package |
-| istio.values | object | `{}` | Values to passthrough to the istio-controlplane chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-controlplane.git |
-| istio.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| istiooperator.enabled | bool | `true` | Toggle deployment of Istio Operator. |
-| istiooperator.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-operator.git"` | |
-| istiooperator.git.path | string | `"./chart"` | |
-| istiooperator.git.tag | string | `"1.13.5-bb.1"` | |
-| istiooperator.flux | object | `{}` | Flux reconciliation overrides specifically for the Istio Operator Package |
-| istiooperator.values | object | `{}` | Values to passthrough to the istio-operator chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-operator.git |
-| istiooperator.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| jaeger.enabled | bool | `true` | Toggle deployment of Jaeger. |
-| jaeger.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/jaeger.git"` | |
-| jaeger.git.path | string | `"./chart"` | |
-| jaeger.git.tag | string | `"2.33.0-bb.0"` | |
-| jaeger.flux | object | `{"install":{"crds":"CreateReplace"},"upgrade":{"crds":"CreateReplace"}}` | Flux reconciliation overrides specifically for the Jaeger Package |
-| jaeger.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| jaeger.sso.enabled | bool | `false` | Toggle SSO for Jaeger on and off |
-| jaeger.sso.client_id | string | `""` | OIDC Client ID to use for Jaeger |
-| jaeger.sso.client_secret | string | `""` | OIDC Client Secret to use for Jaeger |
-| jaeger.values | object | `{}` | Values to pass through to Jaeger chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/jaeger.git |
-| jaeger.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| kiali.enabled | bool | `true` | Toggle deployment of Kiali. |
-| kiali.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/kiali.git"` | |
-| kiali.git.path | string | `"./chart"` | |
-| kiali.git.tag | string | `"1.51.0-bb.3"` | |
-| kiali.flux | object | `{}` | Flux reconciliation overrides specifically for the Kiali Package |
-| kiali.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| kiali.sso.enabled | bool | `false` | Toggle SSO for Kiali on and off |
-| kiali.sso.client_id | string | `""` | OIDC Client ID to use for Kiali |
-| kiali.sso.client_secret | string | `""` | OIDC Client Secret to use for Kiali |
-| kiali.values | object | `{}` | Values to pass through to Kiali chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/kiali |
-| kiali.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| clusterAuditor.enabled | bool | `true` | Toggle deployment of Cluster Auditor. |
-| clusterAuditor.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/cluster-auditor.git"` | |
-| clusterAuditor.git.path | string | `"./chart"` | |
-| clusterAuditor.git.tag | string | `"1.4.0-bb.4"` | |
-| clusterAuditor.flux | object | `{}` | Flux reconciliation overrides specifically for the Cluster Auditor Package |
-| clusterAuditor.values | object | `{}` | Values to passthrough to the cluster auditor chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/cluster-auditor.git |
-| clusterAuditor.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| gatekeeper.enabled | bool | `true` | Toggle deployment of OPA Gatekeeper. |
-| gatekeeper.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/policy.git"` | |
-| gatekeeper.git.path | string | `"./chart"` | |
-| gatekeeper.git.tag | string | `"3.8.1-bb.5"` | |
-| gatekeeper.flux | object | `{"install":{"crds":"CreateReplace"},"upgrade":{"crds":"CreateReplace"}}` | Flux reconciliation overrides specifically for the OPA Gatekeeper Package |
-| gatekeeper.values | object | `{}` | Values to passthrough to the gatekeeper chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/policy.git |
-| gatekeeper.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| kyverno.enabled | bool | `false` | Toggle deployment of Kyverno. |
-| kyverno.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/kyverno.git"` | |
-| kyverno.git.path | string | `"./chart"` | |
-| kyverno.git.tag | string | `"2.2.0-bb.3"` | |
-| kyverno.flux | object | `{}` | Flux reconciliation overrides specifically for the Kyverno Package |
-| kyverno.values | object | `{}` | Values to passthrough to the kyverno chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/kyverno.git |
-| kyverno.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| kyvernopolicies.enabled | bool | `false` | Toggle deployment of Kyverno policies |
-| kyvernopolicies.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/kyverno-policies.git"` | |
-| kyvernopolicies.git.path | string | `"./chart"` | |
-| kyvernopolicies.git.tag | string | `"1.0.1-bb.0"` | |
-| kyvernopolicies.flux | object | `{}` | Flux reconciliation overrides specifically for the Kyverno Package |
-| kyvernopolicies.values | object | `{}` | Values to passthrough to the kyverno policies chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/kyverno-policies.git |
-| kyvernopolicies.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| logging.enabled | bool | `true` | Toggle deployment of Logging (EFK). |
-| logging.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/elasticsearch-kibana.git"` | |
-| logging.git.path | string | `"./chart"` | |
-| logging.git.tag | string | `"0.8.0-bb.1"` | |
-| logging.flux | object | `{"timeout":"20m"}` | Flux reconciliation overrides specifically for the Logging (EFK) Package |
-| logging.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| logging.sso.enabled | bool | `false` | Toggle OIDC SSO for Kibana/Elasticsearch on and off. Enabling this option will auto-create any required secrets. |
-| logging.sso.client_id | string | `""` | Elasticsearch/Kibana OIDC client ID |
-| logging.sso.client_secret | string | `""` | Elasticsearch/Kibana OIDC client secret |
-| logging.license.trial | bool | `false` | Toggle trial license installation of elasticsearch. Note that enterprise (non trial) is required for SSO to work. |
-| logging.license.keyJSON | string | `""` | Elasticsearch license in json format seen here: https://repo1.dso.mil/platform-one/big-bang/apps/core/elasticsearch-kibana#enterprise-license |
-| logging.values | object | `{}` | Values to passthrough to the elasticsearch-kibana chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/elasticsearch-kibana.git |
-| logging.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| eckoperator.enabled | bool | `true` | Toggle deployment of ECK Operator. |
-| eckoperator.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/eck-operator.git"` | |
-| eckoperator.git.path | string | `"./chart"` | |
-| eckoperator.git.tag | string | `"2.3.0-bb.0"` | |
-| eckoperator.flux | object | `{}` | Flux reconciliation overrides specifically for the ECK Operator Package |
-| eckoperator.values | object | `{}` | Values to passthrough to the eck-operator chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/eck-operator.git |
-| fluentbit.enabled | bool | `true` | Toggle deployment of Fluent-Bit. |
-| fluentbit.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/fluentbit.git"` | |
-| fluentbit.git.path | string | `"./chart"` | |
-| fluentbit.git.tag | string | `"0.20.3-bb.0"` | |
-| fluentbit.flux | object | `{}` | Flux reconciliation overrides specifically for the Fluent-Bit Package |
-| fluentbit.values | object | `{}` | Values to passthrough to the fluentbit chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/fluentbit.git |
-| fluentbit.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| promtail.enabled | bool | `false` | Toggle deployment of Promtail. |
-| promtail.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/promtail.git"` | |
-| promtail.git.path | string | `"./chart"` | |
-| promtail.git.tag | string | `"4.2.0-bb.2"` | |
-| promtail.flux | object | `{}` | Flux reconciliation overrides specifically for the Promtail Package |
-| promtail.values | object | `{}` | Values to passthrough to the promtail chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/fluentbit.git |
-| promtail.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| loki.enabled | bool | `false` | Toggle deployment of Loki. |
-| loki.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/loki.git"` | |
-| loki.git.path | string | `"./chart"` | |
-| loki.git.tag | string | `"3.0.5-bb.4"` | |
-| loki.flux | object | `{}` | Flux reconciliation overrides specifically for the Loki Package |
-| loki.strategy | string | `"monolith"` | Loki architecture. Options are monolith and scalable |
-| loki.objectStorage.endpoint | string | `""` | S3 compatible endpoint to use for connection information. examples: "https://s3.amazonaws.com" "https://s3.us-gov-west-1.amazonaws.com" "http://minio.minio.svc.cluster.local:9000" |
-| loki.objectStorage.region | string | `""` | S3 compatible region to use for connection information. |
-| loki.objectStorage.accessKey | string | `""` | Access key for connecting to object storage endpoint. |
-| loki.objectStorage.accessSecret | string | `""` | Secret key for connecting to object storage endpoint. Unencoded string data. This should be placed in the secret values and then encrypted |
-| loki.objectStorage.bucketNames | string | `""` | Bucket Names for Loki as a comma delimited list. examples: "loki-logs" |
-| loki.values | object | `{}` | Values to passthrough to the Loki chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/loki.git |
-| loki.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| tempo.enabled | bool | `false` | Toggle deployment of Tempo. |
-| tempo.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/tempo.git"` | |
-| tempo.git.path | string | `"./chart"` | |
-| tempo.git.tag | string | `"0.15.1-bb.7"` | |
-| tempo.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| tempo.flux | object | `{}` | Flux reconciliation overrides specifically for the Tempo Package |
-| tempo.sso.enabled | bool | `false` | Toggle SSO for Tempo on and off |
-| tempo.sso.client_id | string | `""` | OIDC Client ID to use for Tempo |
-| tempo.sso.client_secret | string | `""` | OIDC Client Secret to use for Tempo |
-| tempo.objectStorage.endpoint | string | `""` | S3 compatible endpoint to use for connection information. examples: "s3.amazonaws.com" "s3.us-gov-west-1.amazonaws.com" "minio.minio.svc.cluster.local:9000" Note: tempo does not require protocol prefix for URL. |
-| tempo.objectStorage.region | string | `""` | S3 compatible region to use for connection information. |
-| tempo.objectStorage.accessKey | string | `""` | Access key for connecting to object storage endpoint. |
-| tempo.objectStorage.accessSecret | string | `""` | Secret key for connecting to object storage endpoint. Unencoded string data. This should be placed in the secret values and then encrypted |
-| tempo.objectStorage.bucket | string | `""` | Bucket Names for Loki as a comma delimited list. examples: "tempo-traces" |
-| tempo.objectStorage.insecure | bool | `false` | Whether or not objectStorage connection should require HTTPS, if connecting to in-cluster object storage on port 80/9000 set this value to true. |
-| tempo.values | object | `{}` | Values to passthrough to the Tempo chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/tempo.git |
-| tempo.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| monitoring.enabled | bool | `true` | Toggle deployment of Monitoring (Prometheus, Grafana, and Alertmanager). |
-| monitoring.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/monitoring.git"` | |
-| monitoring.git.path | string | `"./chart"` | |
-| monitoring.git.tag | string | `"36.2.1-bb.2"` | |
-| monitoring.flux | object | `{"install":{"crds":"CreateReplace"},"upgrade":{"crds":"CreateReplace"}}` | Flux reconciliation overrides specifically for the Monitoring Package |
-| monitoring.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| monitoring.sso.enabled | bool | `false` | Toggle SSO for monitoring components on and off |
-| monitoring.sso.prometheus.client_id | string | `""` | Prometheus OIDC client ID |
-| monitoring.sso.prometheus.client_secret | string | `""` | Prometheus OIDC client secret |
-| monitoring.sso.alertmanager.client_id | string | `""` | Alertmanager OIDC client ID |
-| monitoring.sso.alertmanager.client_secret | string | `""` | Alertmanager OIDC client secret |
-| monitoring.sso.grafana.client_id | string | `""` | Grafana OIDC client ID |
-| monitoring.sso.grafana.client_secret | string | `""` | Grafana OIDC client secret |
-| monitoring.sso.grafana.scopes | string | `""` | Grafana OIDC client scopes, comma separated, see https://grafana.com/docs/grafana/latest/auth/generic-oauth/ |
-| monitoring.sso.grafana.allow_sign_up | string | `"true"` | |
-| monitoring.sso.grafana.role_attribute_path | string | `"Viewer"` | |
-| monitoring.values | object | `{}` | Values to passthrough to the monitoring chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/monitoring.git |
-| monitoring.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| twistlock.enabled | bool | `true` | Toggle deployment of Twistlock. |
-| twistlock.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/twistlock.git"` | |
-| twistlock.git.path | string | `"./chart"` | |
-| twistlock.git.tag | string | `"0.9.0-bb.3"` | |
-| twistlock.flux | object | `{}` | Flux reconciliation overrides specifically for the Twistlock Package |
-| twistlock.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| twistlock.values | object | `{}` | Values to passthrough to the twistlock chart: https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/twistlock.git |
-| twistlock.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.argocd.enabled | bool | `false` | Toggle deployment of ArgoCD. |
-| addons.argocd.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/argocd.git"` | |
-| addons.argocd.git.path | string | `"./chart"` | |
-| addons.argocd.git.tag | string | `"4.9.12-bb.2"` | |
-| addons.argocd.flux | object | `{}` | Flux reconciliation overrides specifically for the ArgoCD Package |
-| addons.argocd.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.argocd.redis.host | string | `""` | Hostname of a pre-existing Redis to use for ArgoCD. Entering connection info will enable external Redis and will auto-create any required secrets. |
-| addons.argocd.redis.port | string | `""` | Port of a pre-existing Redis to use for ArgoCD. |
-| addons.argocd.sso.enabled | bool | `false` | Toggle SSO for ArgoCD on and off |
-| addons.argocd.sso.client_id | string | `""` | ArgoCD OIDC client ID |
-| addons.argocd.sso.client_secret | string | `""` | ArgoCD OIDC client secret |
-| addons.argocd.sso.provider_name | string | `""` | ArgoCD SSO login text |
-| addons.argocd.sso.groups | string | `"g, Impact Level 2 Authorized, role:admin\n"` | ArgoCD SSO group roles, see docs for more details: https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/ |
-| addons.argocd.values | object | `{}` | Values to passthrough to the argocd chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/argocd.git |
-| addons.argocd.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.authservice.enabled | bool | `false` | Toggle deployment of Authservice. if enabling authservice, a filter needs to be provided by either enabling sso for monitoring or istio, or manually adding a filter chain in the values here: values: chain: minimal: callback_uri: "https://somecallback" |
-| addons.authservice.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/core/authservice.git"` | |
-| addons.authservice.git.path | string | `"./chart"` | |
-| addons.authservice.git.tag | string | `"0.5.1-bb.5"` | |
-| addons.authservice.flux | object | `{}` | Flux reconciliation overrides specifically for the Authservice Package |
-| addons.authservice.values | object | `{}` | Values to passthrough to the authservice chart: https://repo1.dso.mil/platform-one/big-bang/apps/core/authservice.git |
-| addons.authservice.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.authservice.chains | object | `{}` | Additional authservice chain configurations. |
-| addons.minioOperator.enabled | bool | `false` | Toggle deployment of minio operator and instance. |
-| addons.minioOperator.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/application-utilities/minio-operator.git"` | |
-| addons.minioOperator.git.path | string | `"./chart"` | |
-| addons.minioOperator.git.tag | string | `"4.4.25-bb.0"` | |
-| addons.minioOperator.flux | object | `{}` | Flux reconciliation overrides specifically for the Minio Operator Package |
-| addons.minioOperator.values | object | `{}` | Values to passthrough to the minio operator chart: https://repo1.dso.mil/platform-one/big-bang/apps/application-utilities/minio-operator.git |
-| addons.minioOperator.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.minio.enabled | bool | `false` | Toggle deployment of minio. |
-| addons.minio.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/application-utilities/minio.git"` | |
-| addons.minio.git.path | string | `"./chart"` | |
-| addons.minio.git.tag | string | `"4.4.16-bb.0"` | |
-| addons.minio.flux | object | `{}` | Flux reconciliation overrides specifically for the Minio Package |
-| addons.minio.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.minio.accesskey | string | `""` | Default access key to use for minio. |
-| addons.minio.secretkey | string | `""` | Default secret key to intstantiate with minio, you should change/delete this after installation. |
-| addons.minio.values | object | `{}` | Values to passthrough to the minio instance chart: https://repo1.dso.mil/platform-one/big-bang/apps/application-utilities/minio.git |
-| addons.minio.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.gitlab.enabled | bool | `false` | Toggle deployment of Gitlab |
-| addons.gitlab.hostnames.gitlab | string | `"gitlab"` | |
-| addons.gitlab.hostnames.registry | string | `"registry"` | |
-| addons.gitlab.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab.git"` | |
-| addons.gitlab.git.path | string | `"./chart"` | |
-| addons.gitlab.git.tag | string | `"6.1.2-bb.1"` | |
-| addons.gitlab.flux | object | `{}` | Flux reconciliation overrides specifically for the Gitlab Package |
-| addons.gitlab.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.gitlab.sso.enabled | bool | `false` | Toggle OIDC SSO for Gitlab on and off. Enabling this option will auto-create any required secrets. |
-| addons.gitlab.sso.client_id | string | `""` | Gitlab OIDC client ID |
-| addons.gitlab.sso.client_secret | string | `""` | Gitlab OIDC client secret |
-| addons.gitlab.sso.label | string | `""` | Gitlab SSO login button label |
-| addons.gitlab.sso.scopes | list | `["Gitlab"]` | Gitlab SSO Scopes, default is ["Gitlab"] |
-| addons.gitlab.sso.issuer_uri | string | `""` | GitLab SSO Issuer URI, Only needed if your SSO is non-Keycloak |
-| addons.gitlab.sso.end_session_uri | string | `""` | GitLab SSO End Session URI, Only needed if your SSO is non-Keycloak |
-| addons.gitlab.sso.uid_field | string | `"preferred_username"` | Gitlab SSO UID field |
-| addons.gitlab.database.host | string | `""` | Hostname of a pre-existing PostgreSQL database to use for Gitlab. Entering connection info will disable the deployment of an internal database and will auto-create any required secrets. |
-| addons.gitlab.database.port | int | `5432` | Port of a pre-existing PostgreSQL database to use for Gitlab. |
-| addons.gitlab.database.database | string | `""` | Database name to connect to on host. |
-| addons.gitlab.database.username | string | `""` | Username to connect as to external database, the user must have all privileges on the database. |
-| addons.gitlab.database.password | string | `""` | Database password for the username used to connect to the existing database. |
-| addons.gitlab.objectStorage.type | string | `""` | Type of object storage to use for Gitlab, setting to s3 will assume an external, pre-existing object storage is to be used. Entering connection info will enable this option and will auto-create any required secrets |
-| addons.gitlab.objectStorage.endpoint | string | `""` | S3 compatible endpoint to use for connection information. examples: "https://s3.amazonaws.com" "https://s3.us-gov-west-1.amazonaws.com" "http://minio.minio.svc.cluster.local:9000" |
-| addons.gitlab.objectStorage.region | string | `""` | S3 compatible region to use for connection information. |
-| addons.gitlab.objectStorage.accessKey | string | `""` | Access key for connecting to object storage endpoint. -- If using accessKey and accessSecret, the iamProfile must be left as an empty string: "" |
-| addons.gitlab.objectStorage.accessSecret | string | `""` | Secret key for connecting to object storage endpoint. Unencoded string data. This should be placed in the secret values and then encrypted |
-| addons.gitlab.objectStorage.bucketPrefix | string | `""` | Bucket prefix to use for identifying buckets. Example: "prod" will produce "prod-gitlab-bucket" |
-| addons.gitlab.objectStorage.iamProfile | string | `""` | NOTE: Current bug with AWS IAM Profiles and Object Storage where only artifacts are stored. Fixed in Gitlab 14.5 -- Name of AWS IAM profile to use. -- If using an AWS IAM profile, the accessKey and accessSecret values must be left as empty strings eg: "" |
-| addons.gitlab.smtp.password | string | `""` | Passwords should be placed in an encrypted file. Example: environment-bb-secret.enc.yaml If a value is provided BigBang will create a k8s secret named gitlab-smtp-password in the gitlab namespace |
-| addons.gitlab.redis.password | string | `""` | Redis plain text password to connect to the redis server. If empty (""), the gitlab charts will create the gitlab-redis-secret with a random password. -- This needs to be set to a non-empty value in order for the Grafana Redis Datasource and Dashboards to be installed. |
-| addons.gitlab.values | object | `{}` | Values to passthrough to the gitlab chart: https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab.git |
-| addons.gitlab.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.gitlabRunner.enabled | bool | `false` | Toggle deployment of Gitlab Runner |
-| addons.gitlabRunner.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab-runner.git"` | |
-| addons.gitlabRunner.git.path | string | `"./chart"` | |
-| addons.gitlabRunner.git.tag | string | `"0.41.0-bb.0"` | |
-| addons.gitlabRunner.flux | object | `{}` | Flux reconciliation overrides specifically for the Gitlab Runner Package |
-| addons.gitlabRunner.values | object | `{}` | Values to passthrough to the gitlab runner chart: https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab-runner.git |
-| addons.gitlabRunner.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.nexus.enabled | bool | `false` | Toggle deployment of Nexus. |
-| addons.nexus.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/nexus.git"` | |
-| addons.nexus.git.path | string | `"./chart"` | |
-| addons.nexus.git.tag | string | `"40.1.0-bb.0"` | |
-| addons.nexus.license_key | string | `""` | Base64 encoded license file. |
-| addons.nexus.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.nexus.sso.enabled | bool | `false` | Toggle SAML SSO for NXRM. -- handles SAML SSO, a Client must be configured in Keycloak or IdP -- to complete setup. -- https://support.sonatype.com/hc/en-us/articles/1500000976522-SAML-integration-for-Nexus-Repository-Manager-Pro-3-and-Nexus-IQ-Server-with-Keycloak#h_01EV7CWCYH3YKAPMAHG8XMQ599 |
-| addons.nexus.sso.idp_data | object | `{"email":"","entityId":"","firstName":"","groups":"","idpMetadata":"","lastName":"","username":""}` | NXRM SAML SSO Integration data |
-| addons.nexus.sso.idp_data.username | string | `""` | IdP Field Mappings -- NXRM username attribute |
-| addons.nexus.sso.idp_data.firstName | string | `""` | NXRM firstname attribute (optional) |
-| addons.nexus.sso.idp_data.lastName | string | `""` | NXRM lastname attribute (optional) |
-| addons.nexus.sso.idp_data.email | string | `""` | NXRM email attribute (optional) |
-| addons.nexus.sso.idp_data.groups | string | `""` | NXRM groups attribute (optional) |
-| addons.nexus.sso.idp_data.idpMetadata | string | `""` | IDP SAML Metadata XML as a single line string in single quotes -- this information is public and does not require a secret |
-| addons.nexus.sso.role | list | `[{"description":"","id":"","name":"","privileges":[],"roles":[]}]` | NXRM Role |
-| addons.nexus.flux | object | `{}` | Flux reconciliation overrides specifically for the Nexus Repository Manager Package |
-| addons.nexus.values | object | `{}` | Values to passthrough to the nxrm chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/nexus.git |
-| addons.nexus.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.sonarqube.enabled | bool | `false` | Toggle deployment of SonarQube. |
-| addons.sonarqube.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/sonarqube.git"` | |
-| addons.sonarqube.git.path | string | `"./chart"` | |
-| addons.sonarqube.git.tag | string | `"1.0.29-bb.2"` | |
-| addons.sonarqube.flux | object | `{}` | Flux reconciliation overrides specifically for the Sonarqube Package |
-| addons.sonarqube.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.sonarqube.sso.enabled | bool | `false` | Toggle SAML SSO for SonarQube. Enabling this option will auto-create any required secrets. |
-| addons.sonarqube.sso.client_id | string | `""` | SonarQube SAML client ID |
-| addons.sonarqube.sso.provider_name | string | `""` | SonarQube SSO login button label |
-| addons.sonarqube.sso.certificate | string | `""` | SonarQube plaintext SAML sso certificate. example: MITCAYCBFyIEUjNBkqhkiG9w0BA.... |
-| addons.sonarqube.sso.login | string | `"login"` | SonarQube login sso attribute. |
-| addons.sonarqube.sso.name | string | `"name"` | SonarQube name sso attribute. |
-| addons.sonarqube.sso.email | string | `"email"` | SonarQube email sso attribute. |
-| addons.sonarqube.sso.group | string | `"group"` | (optional) SonarQube group sso attribute. |
-| addons.sonarqube.database.host | string | `""` | Hostname of a pre-existing PostgreSQL database to use for SonarQube. |
-| addons.sonarqube.database.port | int | `5432` | Port of a pre-existing PostgreSQL database to use for SonarQube. |
-| addons.sonarqube.database.database | string | `""` | Database name to connect to on host. |
-| addons.sonarqube.database.username | string | `""` | Username to connect as to external database, the user must have all privileges on the database. |
-| addons.sonarqube.database.password | string | `""` | Database password for the username used to connect to the existing database. |
-| addons.sonarqube.values | object | `{}` | Values to passthrough to the sonarqube chart: https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/sonarqube.git |
-| addons.sonarqube.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.haproxy.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/haproxy"` | |
-| addons.haproxy.git.path | string | `"./chart"` | |
-| addons.haproxy.git.tag | string | `"1.12.0-bb.0"` | |
-| addons.haproxy.flux | object | `{}` | Flux reconciliation overrides specifically for the HAProxy Package |
-| addons.haproxy.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.haproxy.values | object | `{}` | Values to passthrough to the haproxy chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/haproxy.git |
-| addons.haproxy.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.anchore.enabled | bool | `false` | Toggle deployment of Anchore. |
-| addons.anchore.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/anchore-enterprise.git"` | |
-| addons.anchore.git.path | string | `"./chart"` | |
-| addons.anchore.git.tag | string | `"1.18.6-bb.9"` | |
-| addons.anchore.flux | object | `{"upgrade":{"disableWait":true}}` | Flux reconciliation overrides specifically for the Anchore Package |
-| addons.anchore.adminPassword | string | `""` | Initial admin password used to authenticate to Anchore. |
-| addons.anchore.enterprise | object | `{"enabled":false,"licenseYaml":"FULL LICENSE\n"}` | Anchore Enterprise functionality. |
-| addons.anchore.enterprise.enabled | bool | `false` | Toggle the installation of Anchore Enterprise. This must be accompanied by a valid license. |
-| addons.anchore.enterprise.licenseYaml | string | `"FULL LICENSE\n"` | License for Anchore Enterprise. For formatting examples see https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/anchore-enterprise/-/blob/main/docs/CHART.md#enabling-enterprise-services |
-| addons.anchore.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.anchore.sso.enabled | bool | `false` | Toggle OIDC SSO for Anchore on and off. Enabling this option will auto-create any required secrets (Note: SSO requires an Enterprise license). |
-| addons.anchore.sso.client_id | string | `""` | Anchore OIDC client ID |
-| addons.anchore.sso.role_attribute | string | `""` | Anchore OIDC client role attribute |
-| addons.anchore.database.host | string | `""` | Hostname of a pre-existing PostgreSQL database to use for Anchore. Entering connection info will disable the deployment of an internal database and will auto-create any required secrets. |
-| addons.anchore.database.port | string | `""` | Port of a pre-existing PostgreSQL database to use for Anchore. |
-| addons.anchore.database.username | string | `""` | Username to connect as to external database, the user must have all privileges on the database. |
-| addons.anchore.database.password | string | `""` | Database password for the username used to connect to the existing database. |
-| addons.anchore.database.database | string | `""` | Database name to connect to on host (Note: database name CANNOT contain hyphens). |
-| addons.anchore.database.feeds_database | string | `""` | Feeds database name to connect to on host (Note: feeds database name CANNOT contain hyphens). Only required for enterprise edition of anchore. By default, feeds database will be configured with the same username and password as the main database. For formatting examples on how to use a separate username and password for the feeds database see https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/anchore-enterprise/-/blob/main/docs/CHART.md#handling-dependencies |
-| addons.anchore.redis.host | string | `""` | Hostname of a pre-existing Redis to use for Anchore Enterprise. Entering connection info will enable external redis and will auto-create any required secrets. Anchore only requires redis for enterprise deployments and will not provision an instance if using external |
-| addons.anchore.redis.port | string | `""` | Port of a pre-existing Redis to use for Anchore Enterprise. |
-| addons.anchore.redis.username | string | `""` | OPTIONAL: Username to connect to a pre-existing Redis (for password-only auth leave empty) |
-| addons.anchore.redis.password | string | `""` | Password to connect to pre-existing Redis. |
-| addons.anchore.values | object | `{}` | Values to passthrough to the anchore chart: https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/anchore-enterprise.git |
-| addons.anchore.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.mattermostoperator.enabled | bool | `false` | |
-| addons.mattermostoperator.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost-operator.git"` | |
-| addons.mattermostoperator.git.path | string | `"./chart"` | |
-| addons.mattermostoperator.git.tag | string | `"1.18.1-bb.0"` | |
-| addons.mattermostoperator.flux | object | `{}` | Flux reconciliation overrides specifically for the Mattermost Operator Package |
-| addons.mattermostoperator.values | object | `{}` | Values to passthrough to the mattermost operator chart: https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost-operator/-/blob/main/chart/values.yaml |
-| addons.mattermostoperator.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.mattermost.enabled | bool | `false` | Toggle deployment of Mattermost. |
-| addons.mattermost.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost.git"` | |
-| addons.mattermost.git.path | string | `"./chart"` | |
-| addons.mattermost.git.tag | string | `"7.0.1-bb.1"` | |
-| addons.mattermost.flux | object | `{}` | Flux reconciliation overrides specifically for the Mattermost Package |
-| addons.mattermost.enterprise | object | `{"enabled":false,"license":""}` | Mattermost Enterprise functionality. |
-| addons.mattermost.enterprise.enabled | bool | `false` | Toggle the Mattermost Enterprise. This must be accompanied by a valid license unless you plan to start a trial post-install. |
-| addons.mattermost.enterprise.license | string | `""` | License for Mattermost. This should be the entire contents of the license file from Mattermost (should be one line), example below license: "eyJpZCI6InIxM205bjR3eTdkYjludG95Z3RiOD---REST---IS---HIDDEN |
-| addons.mattermost.ingress | object | `{"gateway":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.mattermost.sso.enabled | bool | `false` | Toggle OIDC SSO for Mattermost on and off. Enabling this option will auto-create any required secrets. |
-| addons.mattermost.sso.client_id | string | `""` | Mattermost OIDC client ID |
-| addons.mattermost.sso.client_secret | string | `""` | Mattermost OIDC client secret |
-| addons.mattermost.sso.auth_endpoint | string | `""` | Mattermost OIDC auth endpoint To get endpoint values, see here: https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost/-/blob/main/docs/keycloak.md#helm-values |
-| addons.mattermost.sso.token_endpoint | string | `""` | Mattermost OIDC token endpoint To get endpoint values, see here: https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost/-/blob/main/docs/keycloak.md#helm-values |
-| addons.mattermost.sso.user_api_endpoint | string | `""` | Mattermost OIDC user API endpoint To get endpoint values, see here: https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost/-/blob/main/docs/keycloak.md#helm-values |
-| addons.mattermost.database.host | string | `""` | Hostname of a pre-existing PostgreSQL database to use for Mattermost. Entering connection info will disable the deployment of an internal database and will auto-create any required secrets. |
-| addons.mattermost.database.port | string | `""` | Port of a pre-existing PostgreSQL database to use for Mattermost. |
-| addons.mattermost.database.username | string | `""` | Username to connect as to external database, the user must have all privileges on the database. |
-| addons.mattermost.database.password | string | `""` | Database password for the username used to connect to the existing database. |
-| addons.mattermost.database.database | string | `""` | Database name to connect to on host. |
-| addons.mattermost.database.ssl_mode | string | `""` | SSL Mode to use when connecting to the database. Allowable values for this are viewable in the postgres documentation: https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS |
-| addons.mattermost.objectStorage.endpoint | string | `""` | S3 compatible endpoint to use for connection information. Entering connection info will enable this option and will auto-create any required secrets. examples: "s3.amazonaws.com" "s3.us-gov-west-1.amazonaws.com" "minio.minio.svc.cluster.local:9000" |
-| addons.mattermost.objectStorage.accessKey | string | `""` | Access key for connecting to object storage endpoint. |
-| addons.mattermost.objectStorage.accessSecret | string | `""` | Secret key for connecting to object storage endpoint. Unencoded string data. This should be placed in the secret values and then encrypted |
-| addons.mattermost.objectStorage.bucket | string | `""` | Bucket name to use for Mattermost - will be auto-created. |
-| addons.mattermost.elasticsearch | object | `{"enabled":false}` | Mattermost Elasticsearch integration - requires enterprise E20 license - https://docs.mattermost.com/deployment/elasticsearch.html Connection info defaults to the BB deployed Elastic, all values can be overridden via the "values" passthrough for other connections. See values spec in MM chart "elasticsearch" yaml block - https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost/-/blob/main/chart/values.yaml |
-| addons.mattermost.elasticsearch.enabled | bool | `false` | Toggle interaction with Elastic for optimized search indexing |
-| addons.mattermost.values | object | `{}` | Values to passthrough to the Mattermost chart: https://repo1.dso.mil/platform-one/big-bang/apps/collaboration-tools/mattermost/-/blob/main/chart/values.yaml |
-| addons.mattermost.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.velero.enabled | bool | `false` | Toggle deployment of Velero. |
-| addons.velero.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/cluster-utilities/velero.git"` | |
-| addons.velero.git.path | string | `"./chart"` | |
-| addons.velero.git.tag | string | `"2.30.1-bb.0"` | |
-| addons.velero.flux | object | `{}` | Flux reconciliation overrides specifically for the Velero Package |
-| addons.velero.plugins | list | `[]` | Plugin provider for Velero - requires at least one plugin installed. Current supported values: aws, azure, csi |
-| addons.velero.values | object | `{}` | Values to passthrough to the Velero chart: https://repo1.dso.mil/platform-one/big-bang/apps/cluster-utilities/velero/-/blob/main/chart/values.yaml |
-| addons.velero.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.keycloak.enabled | bool | `false` | Toggle deployment of Keycloak. if you enable Keycloak you should uncomment the istio passthrough configurations above istio.ingressGateways.passthrough-ingressgateway and istio.gateways.passthrough |
-| addons.keycloak.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/keycloak.git"` | |
-| addons.keycloak.git.path | string | `"./chart"` | |
-| addons.keycloak.git.tag | string | `"18.2.1-bb.0"` | |
-| addons.keycloak.database.host | string | `""` | Hostname of a pre-existing database to use for Keycloak. Entering connection info will disable the deployment of an internal database and will auto-create any required secrets. |
-| addons.keycloak.database.type | string | `"postgres"` | Pre-existing database type (e.g. postgres) to use for Keycloak. |
-| addons.keycloak.database.port | int | `5432` | Port of a pre-existing database to use for Keycloak. |
-| addons.keycloak.database.database | string | `""` | Database name to connect to on host. |
-| addons.keycloak.database.username | string | `""` | Username to connect as to external database, the user must have all privileges on the database. |
-| addons.keycloak.database.password | string | `""` | Database password for the username used to connect to the existing database. |
-| addons.keycloak.flux | object | `{}` | Flux reconciliation overrides specifically for the OPA Gatekeeper Package |
-| addons.keycloak.ingress | object | `{"cert":"","gateway":"passthrough","key":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.keycloak.ingress.key | string | `""` | Certificate/Key pair to use as the certificate for exposing Keycloak Setting the ingress cert here will automatically create the volume and volumemounts in the Keycloak Package chart |
-| addons.keycloak.values | object | `{}` | Values to passthrough to the keycloak chart: https://repo1.dso.mil/platform-one/big-bang/apps/security-tools/keycloak.git |
-| addons.keycloak.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.vault.enabled | bool | `false` | Toggle deployment of Vault. |
-| addons.vault.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/vault.git"` | |
-| addons.vault.git.path | string | `"./chart"` | |
-| addons.vault.git.tag | string | `"0.20.1-bb.4"` | |
-| addons.vault.flux | object | `{}` | Flux reconciliation overrides specifically for the Vault Package |
-| addons.vault.ingress | object | `{"cert":"","gateway":"","key":""}` | Redirect the package ingress to a specific Istio Gateway (listed in `istio.gateways`). The default is "public". |
-| addons.vault.ingress.key | string | `""` | Certificate/Key pair to use as the certificate for exposing Vault Setting the ingress cert here will automatically create the volume and volumemounts in the Vault package chart |
-| addons.vault.values | object | `{}` | Values to passthrough to the vault chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/vault.git |
-| addons.vault.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
-| addons.metricsServer.enabled | string | `"auto"` | Toggle deployment of metrics server Acceptable options are enabled: true, enabled: false, enabled: auto true = enabled / false = disabled / auto = automatic (Installs only if metrics API endpoint is not present) |
-| addons.metricsServer.git.repo | string | `"https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/metrics-server.git"` | |
-| addons.metricsServer.git.path | string | `"./chart"` | |
-| addons.metricsServer.git.tag | string | `"3.8.0-bb.2"` | |
-| addons.metricsServer.flux | object | `{}` | Flux reconciliation overrides specifically for the metrics server Package |
-| addons.metricsServer.values | object | `{}` | Values to passthrough to the metrics server chart: https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/metrics-server.git |
-| addons.metricsServer.postRenderers | list | `[]` | Post Renderers. See docs/postrenders.md |
+## Navigating our documentation
-## Contributing
+Big Bang Documentation is located in the following locations:
-Please see the [contributing guide](./CONTRIBUTING.md) if you are interested in contributing to Big Bang.
+- [Developer Contribution Documentation](./docs/developer)
+- [Key Big Bang Concept Overviews](./docs/understanding_bigbang)
+- [User Guides for Big Bang](./docs/guides/)
+- [Big Bang Prerequisites](./docs/prerequisites/)
+- [Big Bang Example Configurations](./docs/example_configs/)
\ No newline at end of file
diff --git a/charter/BigBang.md b/charter/BigBang.md
deleted file mode 100644
index 1f1c22c3eba4d48fe2d93ea928318845b384212b..0000000000000000000000000000000000000000
--- a/charter/BigBang.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Big Bang
-
-The end consumable of the Big Bang team is a single consumable that allows the installation of all supported [Big Bang Packages](BigBangPackages.md).
diff --git a/charter/DevCIWorkflow.md b/charter/DevCIWorkflow.md
deleted file mode 100644
index 4aee57928e28ded5e72b7ed1aa3d25ba905502b4..0000000000000000000000000000000000000000
--- a/charter/DevCIWorkflow.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Big Bang Developer / CI Workflow
-
-This diagram overviews the BigBang workflow that Developers will use in the processes of feature development, merge request submission, and subsequent release merges.
-
-This diagram also overviews the specific CI pipelines that currently exist to assist and accelerate these general processes.
-
-
-
-[Link to draw.io diagram file](diagrams/dev_ci_workflow.drawio). This diagram file should be modified on draw.io and exported into this repository when the developer / ci workflow changes. It is provided here for ease of use.
diff --git a/charter/DocumentationLocations.md b/charter/DocumentationLocations.md
deleted file mode 100644
index 1cb4a5495eafcf9555721297ee3ecfee004649ac..0000000000000000000000000000000000000000
--- a/charter/DocumentationLocations.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Documentation Locations
-
-> This charter doc represents the future state we are working toward
-
-## BigBang Docs:
-
-### Where is the best place to look for documentation on BigBang?
-
-- https://repo1.dso.mil/platform-one/big-bang/bigbang/-/tree/master/docs/
-- Our goal is to have near 100% of publicly sharable docs in this centralized location to act as a single source of truth where all documentation can be found and help move docs out of IL2 Confluence and Private Repos to better support the open source community.
-
-### What types of documentation can be found in the docs folder?
-
-- Developer Contribution Docs
-- Docs to help understand BigBang (At a concrete level, what the value add is, and Architecture Diagrams)
-- Deployment Prerequisites
-- Deployment Docs for Internet Connected and Disconnected deployments
-
-
-## BigBang Package Docs:
-
-### Where is the best place to look for documentation on BigBang Packages?
-
-- Our goal is to have these docs available on a webpage hosted on the BigBang Cluster using Hugo
- (https://docs.bigbang.dev by default) (look [here](./PackageDocumentation.md) for more info)
-- Currently the docs are hosted for consumption on https://docs-bigbang.dso.mil/
-- This allows us to support a centralized location for package configuration documentation, while allowing support for dynamically added versions of distributed packages in a maintainable way.
diff --git a/charter/GitlabLabels.md b/charter/GitlabLabels.md
deleted file mode 100644
index 430ed4949c5f825d36f9a598f097bfac7438b933..0000000000000000000000000000000000000000
--- a/charter/GitlabLabels.md
+++ /dev/null
@@ -1,180 +0,0 @@
-# GitLab Labels
-
-[[_TOC_]]
-
-## Epics
-
-Epics are required to have `priority`, `size` and `status` labels.
-
-### Epic Label `status`
-
-Status captures the state of the Epic
-
-`status::to-do`
-: This Epic is being identified and worked on by the Maintainers.
-
-`status::review`
-: The Epic is ready for review by the engineering team. Team can re-assign to `status::to-do` when more detail is needed.
-
-`status::ready`
-: The epic is accepted by the team and ready for breakdown of work as priority dictates.
-
-`status::doing`
-: Work has been broken out from this epic and is assigned to milestones for completion
-
-#### `priority::1`
-
-`priority::1` issues are causing runtime issues in production environments. These issues justify a patch of a release.
-
-#### `priority::2`
-
-`priority::2` TBD
-
-#### `priority::3`
-
-`priority:: 3` issues are defined by bugs that degrade system performance, but workarounds are available.
-
-#### `priority::4`
-
-`priority:: 4` TBD
-
-#### `priority::5`
-
-`priority::5` issues are superficial and do not have any impact on the functioning of production systems
-
-The `size` label helps identify the scope of work needed as part of the epic
-
-`size::small`
-: Sufficiently small enough to be completed by an engineer in a two week period
-
-`size::medium`
-: A small number of engineers could complete this in a two week period
-
-`size::large`
-: This epic should be broken down further into consumable sub-epics
-
-`size::xl`
-: This epic needs to be broken down further to be able to be tackled in a sprint
-
-## Issues
-
-Issues are required to have `status`, `priority` and `kind` labels.
-
-Generally, all issues derived from an Epic should have a `priority` value set to the `priority` of the epic its a part of. The priority of issues that are not part of an Epic will need to be determined by a package owner or maintainer.
-
-### Issue Label `kind`
-
-The `kind` label shows the type of work that needs to be accomplished.
-
-`kind::bug`
-: Issues related to BigBang not functioning as expected.
-
-`kind::maintenance`
-: Catch all kind that captures administrative tasking for the BigBang project
-
-`kind::ci`
-: Issues related to the CI/CD, developer workflows and/or the release process.
-
-`kind::docs`
-: Issues related to documentation.
-
-`kind::feature`
-: Creation of a new capability for BigBang and/or one of its packages
-
-`kind::enhancement`
-: Improvement of an existing capability to work more efficiently in specific environments
-
-`kind::test`
-: Improvements on testing for individual packages or Big Bang. Does not change the actual CI/CD pipelines, just enhances the test suite.
-
-### Issue Label `status`
-
-Status captures the state of the issue
-
-`status::blocked`
-: Blocked issues have an external dependency that needs to be solved before work can be completed. This may be other Big Bang issues or hardening of IronBank images. If blocked by an IronBank issue, the `ironbank` label should also be applied
-
-`status::doing`
-: Work is actively being done on this issue. At this point it should have an assignee
-
-`status::review`
-: The issue is ready to be reviewed by a Maintainer
-
-### Issue Package Labels
-
-Package labels are identified by their package name and serve two purposes.
-
-> Packages owners subscribe to the package labels for their packages and will be notified when a new issue or merge request is created with the label.
-
-## Merge Requests
-
-Merge Requests are required to have `status` and `kind` labels.
-
-### Merge Requests Label `status`
-
-Status captures the state of the Merge Request
-
-#### `status::review`
-
-The Epic is ready for review by the engineering team. Team can re-assign to `status::to-do` when more detail is needed.
-
-#### `status::ready`
-
-The epic is accepted by the team and ready for breakdown of work as priority dictates.
-
-#### `status::doing`
-
-Work has been broken out from this epic and is assigned to milestones for completion
-
-#### `status::blocked`
-
-Epic is blocked by an external dependency that needs to be solved before work can be completed. This may be other Big Bang Epic or an Epic from another ValueStream.
-
-### Priority
-
-#### `priority::1`
-
-Top of the backlog and should be broken down and worked on when cycles become available.
-
-#### `priority::2`
-
-TBD
-
-#### `priority::3`
-
-Medium term delivery providing long term value.
-
-#### `priority::4`
-
-TBD
-
-#### `priority::5`
-
-A nice to have, but not needed to advance the product.
-
-### Size
-
-The `size` label helps identify the scope of work needed as part of the epic
-
-#### `size::small`
-
-Sufficiently small enough to be completed by an engineer in a two week period
-
-`status::doing`
-: Work is actively being done on this Merge Request
-
-`status::review`
-: The Merge Request is ready to be reviewed by a Maintainer
-
-### Merge Requests Packages Label
-
-The package label controls which addons are deployed as part of CI. If a label is present for an addon, the GitLab testing framework will enable this addon and ensure its tested as part
-
-`test-ci::infra`
-: The test CI `infra` label for a Merge Request causes the full e2e CI job to run, which includes provisioning Kubernetes clusters in AWS.
-
-`test-ci::release`
-: The test CI `release` label for a Merge Request causes all release CI jobs to run, including bundling of airgap artifacts.
-
-`charter`
-: This Merge Request has a proposed change to the Charter
diff --git a/charter/Glossary.md b/charter/Glossary.md
deleted file mode 100644
index 65cf6e0652c57b91449af2a5839fcba6b05b0654..0000000000000000000000000000000000000000
--- a/charter/Glossary.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Glossary
-
-Big Bang Application
-: Is an application deployable onto Kubernetes using manifests inside the Big Bang Application Repository that meets all the requirements of [Package Requirements](PackageRequirements.md).
-
-Release
-: A release is any change to the manifests that would be installed when referencing this application. It includes a change in Image tag, as well as modifications to the structure of any manifests that define the application deployment.
diff --git a/charter/New GitLab Epic Checklist Template b/charter/New GitLab Epic Checklist Template
deleted file mode 100644
index 436565f12c946f8c9e5338bdb5c18576578dda31..0000000000000000000000000000000000000000
--- a/charter/New GitLab Epic Checklist Template
+++ /dev/null
@@ -1,73 +0,0 @@
-# New Epic Checklist Template
-
-# Feature Request
-
-## Why
-
-> Insert the purpose of the Epic or sub-epic here*
-
-## Proposed Solution
-
-> Insert proposed solution, with relevant links here*
-
-## Definition of Done Checklist
-
-**Package:**
-
-- [ ] Do you have a 'main' branch that is default and protected?
-- [ ] Are all other branches merged or deleted? For master and dev branches, tag the branch commit before deleting the branch so we can retrieve it if necessary. Exception: branches labeled release
-- [ ] Does the repo contain only the following directories: chart, docs, tests? All other directories should be deleted.
-- [ ] Is there a 'CODEOWNERS' file containing some code owners?
-- [ ] Is there a 'CHANGELOG.md' file with initial changes?
-- [ ] Is there a 'README.md' file documenting basic use?
-- [ ] Is there a 'CONTRIBUTING.md' file outlining how a new person can contribute?
-- [ ] Is there a '.gitlab-ci.yml' pipeline setup pointing to a pipeline template?
-- [ ] Is there a 'tests/test-values.yaml' file setup to provide default values for the pipeline? This must include image pull secret references.
-- [ ] Is there a 'chart/Kptfile' that points to the upstream chart used in the repo? Exception: Not needed if upstream chart is not used.
-- [ ] Does the upstream chart version deploy the application version used in Iron Bank (or as close as possible)? This will help avoid incompatible configuration settings.
-- [ ] Have you run helm dep up and added all .tgz file dependencies in 'chart/charts' to the repo?
-- [ ] Have you updated 'chart/requirements.yaml' or 'chart/Chart.yaml' to point to the 'file://./charts/<file>.tgz' dependencies?
-- [ ] If the chart has a web interface, have you added a VirtualService using hostname that is conditionally added if istio.enabled is true? Verify this works using the web address.
-- [ ] If the chart integrates with Prometheus monitoring, have you added a Service and ServiceMonitor that are conditionally added if monitoring.enabled is true? Verify this using Prometheus to check targets.
-- [ ] Does your package have resource requests and limits set and equal to each other?
-- [ ] Do you have a tag on your main branch for the Big Bang release version of the package?
-- [ ] Have all of your images been updated to pull from registry1.dso.mil. Exception: If there is no Iron Bank image, are you pulling from registry.dso.mil?
-- [ ] If the package supports SSO, have you integrated SSO settings? Needs clarification
-- [ ] If the package requires a database, have you integrated external database settings? Needs clarification
-- [ ] If the package requires storage, have you integrated external storage (e.g. MinIO) settings? Needs clarification
-- [ ] Are all secrets and certificates removed from the repo? All secrets should be references or randomly generated during deployment.
-
-**Big Bang:**
-
-- [ ] Have you added a 'namespace.yaml' in 'chart/template's that sets up the package's namespace
-- [ ] Have you added pull secret creation to a resource? This may be in the 'namespace.yaml' file.
-- [ ] Have you added a 'gitrepository.yaml' in 'chart/templates' that sets up a flux GitRepository resource pointing to the package's git repository?
-- [ ] Have you added a 'helmrelease.yaml' in 'chart/templates' that sets up a flux HelmRelease resource pointing to the package's helm chart?
-- [ ] Have you added default values to the HelmRelease that need to be passed downstream to the package? For example: hostname, istio.enabled, monitoring.enabled.
-- [ ] Have you added image pull secret references to the HelmRelease to be passed downstream to the package?
-- [ ] Have you added other package dependencies to the HelmRelease to insure deployment order?
-- [ ] Have you added a key for '<package>.yaml' into 'chart/templates/values.yaml' so override values can be passed downstream to the package?
-- [ ] Have you added a valuesFrom configuration in the HelmRelease pointing to the values secret with a valuesKey equal to '<package>.yaml'?
-- [ ] Have you added the package into 'chart/values.yaml' under addons? Exception: core apps do not go under addons.
-- [ ] Have you added enabled: false to your 'chart/values.yaml' and conditional statements on enabled: true for your namespace, pull secret, git repository, and helm release?
-- [ ] Have you added git repo configuration to 'chart/values.yaml' pointing to the packages git repo, helm chart path, and tag.
-- [ ] Have you added a values: {} placeholder for you package in 'chart/values.yaml'?
-- [ ] Have you added any applicable default values from Fences and Party Bus to the package? Exception: Infrastructure specific implementations (e.g. AWS)
-- [ ] Have you verified that additional details on definition of done need to be added for:
-- Database integration
-- Storage (minio) integration
-- Certificates?
-- SSO integration
-
-**Testing:**
-
-- [ ] Have you verified the CI/CD pipeline passes?
-- [ ] Have you verified the application is available via web URL (if applicable)?
-- [ ] Have you verified you can login via SSO with your Platform One account (if applicable)?
-- [ ] Have you verified you Prometheus is scraping data from monitoring endpoints on the application (if applicable)?
-- [ ] Have you verified the application has database connectivity to the external database (if applicable)?
-- [ ] Have you verified the application has storage connectivity to the external storage (if applicable)?
-
-## Future Work (as separate issues)
-
-- [ ] SSO is integrated as BigBang values
diff --git a/charter/NewPackageRequests.md b/charter/NewPackageRequests.md
deleted file mode 100644
index 67ed2e1cd53939b75843b08013f371bacd91e125..0000000000000000000000000000000000000000
--- a/charter/NewPackageRequests.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# New Big Bang Packages
-
-This is the process for adding a package into Big Bang.
-
-## Submit New Big Bang Package Proposal to the BB Technical Oversite Committee
-
-[BB TOC New Package Proposal](https://repo1.dso.mil/platform-one/p1toc/-/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=)
-
-A shepherd will be assigned to the project to create a repo in the [BB sandbox](https://repo1.dso.mil/platform-one/big-bang/apps/sandbox)
-
-### Process
-
-New packages packages will follow the [BBTOC process](https://repo1.dso.mil/platform-one/bbtoc/-/tree/master/process) from Sandbox -> Incubating -> Graduated
diff --git a/charter/PackageDocumentation.md b/charter/PackageDocumentation.md
deleted file mode 100644
index 85b8c519569547577896913e74bb2a54044829f7..0000000000000000000000000000000000000000
--- a/charter/PackageDocumentation.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# Package Documentation
-
-## Documentation Needed
-
-For every package, we need to inform users how to configure the application.
-This includes:
-
-* Pre-installation configuration parameters
-* Post-installation package configuration
-* SSO Integration
-
-## Delivery Method
-
-The documentation should be versioned along-side the package as it is released. The end user also needs a consistent way to view this documentation when BigBang and addons are installed into a Kubernetes Cluster. This should over time have parity with features that are offered on Party Bus.
-
-## Tooling
-
-### Needs
-
-* Documentation should be easily accessible to an end user when BigBang is installed
-* Needs to be air-gapped friendly for those in disconnected environments
-* Links should be clickable within the documentation. i.e. sonarqube.bigbang.dev might be sonarqube.customer.mil
-
-### What is Hugo
-
-Hugo is a website template engine. It can take a group of files and create a static website from them. Input can be a variety of formats including markdown.
-
-### BigBang Usage of Hugo
-
-Since we already write documentation in markdown, little work will be needed to convert these markdown files into something Hugo can render. The idea is to enforce a directory structure for the documentation so that Hugo can pull in relevant documentation and render it once installed.
-
-The documentation should include:
-
-* Purpose of the tool or add-on
-* Recommended post-installation configuration
-* Optional post-installation configuration
-* Additional configuration that can be done on the tool through automation
-
-## Hugo Specifics
-
-### How it works
-
-1. Each package contains a docs folder with the file structure below.
-2. When the documentation package spins up, it reaches out to all the relevant repos and downloads the docs folder into the hugo container.
-3. The container than does a hugo compile with all the documentation to give us our static site.
-
-### Directory Structure
-
-```text
-package
-|--docs
- | index.html [landing page for application within hugo]
- | overview.md [Overview of application, purpose, and default config options]
- | keycloak.md [Manual or automated steps to configure sso]
- | example-optional-config.md [Additional files for optional configuration for the app]
-```
-
-### Formatting Needed
-
-Each file should start with a block that looks as follows:
-
-```text
-+++
-draft = false
-
-title = "ArgoCD Overview"
-author = "Big Bang Team"
-
-virtualServices = ["argocd"]
-+++
-```
-
-By including this at the top of a markdown file, hugo can now render this page.
-
-### CI/CD pipeline additions
-
-* Ensure that docs meet the standards when changes occur
diff --git a/charter/PackageRequirements.md b/charter/PackageRequirements.md
deleted file mode 100644
index eec0e5e0dd9e2cded3733f63494c4ef894e91880..0000000000000000000000000000000000000000
--- a/charter/PackageRequirements.md
+++ /dev/null
@@ -1,109 +0,0 @@
-# Package Requirements
-
-All Big Bang Packages shall adhere to the following requirements. Where possible, each package shall validate these requirements in their CI/CD processes
-
-[[_TOC_]]
-
-## GitLab Project Settings
-
-* The `main` branch should be default in each project
-* Merge Requests should require 1 approver
-* The `main` branch should be protected:
- * Developers + Maintainers should be allowed to merge.
- * No one should be allowed to push and it should allow
- * CODEOWNERs approval should be allowed
-* There should exist a protected tag with the wildcard `*-bb*`
-
-## PR-X. Kubernetes Cluster Requirements
-
-Each package will work with any cluster under the following criteria.
-
-* Kubernetes Versions "Latest -2". Current latest is 1.20, so also supports 1.19 and 1.18.
-* [Cloud Native Computing Federation Kubernetes Certified Distribution](https://www.cncf.io/certification/software-conformance/).
-* Default Storage Class with RWO
-
-## PR-X. Iron Bank Images
-
-Big Bang Package shall be configured to use Iron Bank images. The images used from Iron Bank __must__ be _fully_ approved and _functional_ to be in compliance with the Big Bang baseline security posture.
-
-Please see [New Package Requests](NewPackageRequests.md) and the [BBTOC process](https://repo1.dso.mil/platform-one/bbtoc/-/tree/master/process) for additional pre-requisites.
-
-## PR-X. Packages are Helm Charts
-
-All packages that the Big Bang product consume are helm charts. This decision is explored in depth in the ADR [here](http://about:blank). The quick summary is that helm provides the best tools for the problem statement that Big Bang is built to address: an opinionated yet configurable deployment of the Platform One baseline.
-
-### Helm Chart Types
-
-Baselining off of the assumption that all packages are helm charts, we can identify _two_ different types of packages:
-
-#### Upstream Helm Charts
-
-Many of the tools and applications that BigBang deploys have actively maintained helm charts, rather than re-inventing the wheel, it is encouraged to leverage charts maintained by vendors or the community.
-
-The unfortunate downside to helm is the lack of chart customization _without_ forking from upstream. While there are several options out there (post-rendering, etc...) that are slowly becoming more widespread, the unfortunate reality is upstream charts that BigBang consumes must be forked into repo1 and the appropriate changes must be made.
-
-Forked upstream helm charts will be configured with the appropriate BigBang _additions_, and in rare cases, _modifications_. They will be versioned in accordance with BigBangs [package versioning scheme](#pr-x.-package-versioning-scheme).
-
-#### Custom Helm Charts
-
-In the case where an accepted upstream helm chart does not exist, BigBang will create and maintain it's own custom helm chart for the package in question. The helm chart will be in conformance with the [Package Standards](#pr-x.-package-standards).
-
-### Documentation for how to upgrade the Package helm charts
-
-The Package chart should include maintenance documentation that describes
-1. The process for upgrading
-2. How to test the upgrade
-3. Documentation for changes made to the upstream chart.
-
-This documentation will be located in each Package repo and named `/docs/DEVELOPMENT_MAINTENANCE.md`. The document should be linked from the top level `/CONTRIBUTING.md` in the "To contribute a change" section item #2.
-
-## PR-X. Package Standards
-
-The common components that each package will have are defined in the following folder layout:
-
-```shell
-├── CODEOWNERS # GitLab Code Owners for Package Owners/Understudies.
-├── README.md # top level summary of package
-├── docs/ # detailed documentation folder describing package consumption details and assumptions
-├── tests/
- ├── cypress # folder containing e2e tests using the cypress test framework
-├── chart/ # Folder containing helm chart
- ├── templates # folder helm chart templates
- ├── tests # folder containing helm chart tests
-```
-
-## PR-X. CI/CD pipeline is required for each Big Bang Package
-
-Each package shall contain a .gitlab-ci.yml file at the top of the package repo. This file shall reference the pipeline CI/CD infrastructure
-files and include the following contents:
-
-```shell
-include:
- - project: 'platform-one/big-bang/pipeline-templates/pipeline-templates'
- ref: master
- file: '/templates/package-tests.yaml'
-```
-
-## PR-X. Dependencies must be a Big Bang Package
-
-If a Package has a dependency on another Package to function, the dependency shall also be a Big Bang Package
-
-## PR-X. Dependency Matrix
-
-Each Package will clearly articulate in documentation any dependent Big Bang Package and versions.
-
-## Branching
-
-Each package will have a default branch of `main`. Immutable tags will be used to identify releases and will follow a semver versioning scheme. For more information, see the [versioning](#pr-x.-package-versioning-scheme) section.
-
-## Package Standards
-
-* Helm Packages contain one kubernetes object definition
-
-* Helm dependency manage charts dependencies in Chart.yaml and the dependency chart can be enabled or disabled using condition.
-* All Chart names are lower case letters and numbers, separated with dashes. No dots, uppercase or underscores.
-* Helm Chart values variable names should begin with a lowercase letter and words should be separated with Camel case
-* Helm chart dependency version,use version ranges instead of pinning to an exact version.
- version: ~1.2.3
-* There should be a Helm values file located at `tests/test-values.yaml` used for pipeline testing.
-* Charts should support `affinity` and `nodeSelector` configuration for all components. If there is only one type of `Pods`, then a single, top level value shall be provided, otherwise there should be `affinity` and `nodeSelector` regions for each component. See [the Kubernetes Docs](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) for more information
diff --git a/charter/README.md b/charter/README.md
deleted file mode 100644
index b0092e5c6abf89bf92f5126d22f2c5609cbe8c5d..0000000000000000000000000000000000000000
--- a/charter/README.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Big Bang
-
-## Scope
-
-Big Bang's scope is to provide publicly available installation manifests for:
-
-* a specific set of packages that adhere to the [DevSecOps Reference Architecture](https://software.af.mil/dsop/documents/#documents). The set of packages are listed here: [Big Bang Application List](BigBangPackages.md)
-* packages that facilitate development of applications that adhere to the DevSecOps Reference Architecture
-
-Big Bang also builds tooling around the testing and validation of Big Bang packages. These tools are provided as is, without support.
-
-## Big Bang Packages
-
-A Big Bang Package (BBP) is manifests that adhere to the requirements outlined in [Application Requirements](PackageRequirements.md).
-
-Each BBP has a set of Owners whose responsibility is outlined in [Package Owners](PackageOwner.md).
-
-Each BBP follows its own release cycle adhering to at least the requirements outlined in [Release Process](ReleaseProcess.md).
-
-## Change to the Charter
-
-All changes to the charter must be requested via Merge Request into the master branch.
-
-## Bi-weekly Meetings
-
-The Big Bang project will have a bi-weekly meeting to discuss global issues that are occurring across applications. Meeting minutes/notes will be kept and posted in a separate repository, and all meetings will be recorded and hosted for public availability. All policy decisions can be talked about during these meetings, but nothing is final until merged into this repository, following the requirements for updating the charter.
diff --git a/charter/Scratch.md b/charter/Scratch.md
deleted file mode 100644
index df226393b2d08ef65095b36a852275ede2ed535a..0000000000000000000000000000000000000000
--- a/charter/Scratch.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Scratch
-
-Comments from meetings
-
-## Apps
-
-* Should any product need to be licence (e.g. why Anchore Enterprise and not Anchore)
-* Should everything used by apps be internal? E.g. Postgres required for Keycloak
-* Which of Anchore vs Anchore Enterprise
-
-* Consistent Interface. Only "supported" BigBang configuration
-
-Testing stuff
-
-## Kubernetes Tools E2E Testing Frameworks
-
-### Each Applications E2E tests
-
-Is there a way to get each application to run its own e2e tests against the deployed version?
-
-e.g. for Argo:
-<https://github.com/argoproj/argo-cd/blob/master/.github/workflows/ci-build.yaml>
-
-### Istio
-
-Istio uses Prow: <https://github.com/istio/test-infra>
-
-### KUTTL
-
-KUTTL allows for the verification of Kubernetes objects (and status) based on application of various kubernetes yaml objects.
-This easily allows for testing the health of all the objects (per status fields), but doesn't provide integration tests unless we
-build all the integration tests into CRDs or into Kubernetes Jobs:
-
-APP
-
-* manifests/linting
-* k3d healthy"
-* smoke tests
-
-Integration Tests
-*
-
-Single release of all app versions in single place. Tested by BB
-
-Customer extensions need to be tested in their own moc environment
-
-Common Integration:
-
-* "App of Apps"
-
-Mock Integration environments
-
-* sample implementation of customer
-
-## Keycloak
-
-Table discussion
-
-API:*
-
-* can't change image tags
-* can change repo to allow for airgapped repos
diff --git a/charter/SprintPlanning.md b/charter/SprintPlanning.md
deleted file mode 100644
index c48b35244655cd65fabee47e84e83ca21302bd3a..0000000000000000000000000000000000000000
--- a/charter/SprintPlanning.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Product Team
-
-Responsible for building the COMMON Big Bang product.
-
-## Product Team Sprint Planning
-
-### Normal Rhythm
-
-* Two week sprints starting on a Tuesday
-* Continue to improve planning every week
-* All team members who have capacity to work on the PRODUCT backlog should attend the planning session
-
-### Work Breakdown
-
-* The Big Bang PRODUCT work will be continuously updated within GitLab by the Big Bang Product Manager, Anchors, and Anchor Shanks
-* The pre-planning activity will execute the following planning steps:
-
-1. Review current team objectives
-1. (Re-)prioritize work at the Epic level
-1. Assess ( ballpark ) amount of the work the team can accomplish within the next week
-
-* The planning activity will execute the following planning steps per planning "team":
-
-1. Review/update the currently OPEN and prioritized Epics provided by the pre-planning activity
-1. Decompose the Epic work into stories by writing new or updating existing stories in Jira to accomplish the Epic objectives
-1. Identify and capture any intra-story dependencies in Jira
-1. Prioritize the stories to be accomplished
-1. Add stories to the sprint backlog roughly equivalent to the team's capacity
-
-### Sprint Execution
-
-* Daily PRODUCT team standup -
-Should discuss EPIC level issues ( dependencies, issues,etc) and be less than 15 minutes
-* Daily EPIC team scrums - team members brief based on Jira Story or Task
-
-1. Review accomplishments in the last 24 hours
-1. Planned work in the next 24 hours
-1. Any blockers or helps required
-1. Individual Stories will be accepted
-1. Sprint retro ( bi-weekly to start on Thursday to inform Tues planning)
-1. Sprint DEMO - working software
-1. [FUTURE] Team capacity planning
-
-### Core Concepts
-
-* Succeed or fail as a team
-* Work pairing is highly encouraged
-* Collaboration/Communication will be key to team success
-* Look for ways to improve the PRODUCT and the process
diff --git a/charter/Support.md b/charter/Support.md
deleted file mode 100644
index 9027d8d0daa01a255494eb0db1146e67ff36a379..0000000000000000000000000000000000000000
--- a/charter/Support.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Support
-
-Big Bang will provide support for all Big Bang Applications. This document outlines the support model from the Big Bang team:
diff --git a/charter/TeamRhythm.md b/charter/TeamRhythm.md
deleted file mode 100644
index 2b3e552497fddb493e2c49d84ad6a4436084c690..0000000000000000000000000000000000000000
--- a/charter/TeamRhythm.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Team Rhythm
-
-## Internal Team meetings
-
-|Title| Purpose |Attendees | Frequency|Days|
-|:---|:----- |:----------|:--------------|:-------------------|
-|PM Tagup|Discuss Cross team issues and priorities for the week|Integration PM & Product PM|Weekly|M|
-|Team Tagup|Discuss overall team issues|BB Team|Weekly|T|
-|Sprint Planning|Plan sprint work|Epic Teams|Weekly|T|
-|T3|Team technical collab|BB Team|Weekly|R|
-|Charter Review|Charter pull request review|BB Team|Weekly|R|
-|JETT Tagup|PM & Anchor tagup & alignment|JETT|Daily|M-F|
-|Integration Standup|Discuss priorities & issues|Integration Team|Daily|M-F|
-|Product Standup|Discuss priorities & issues|Product Team|Daily|M-F|
-|Product Epic Teams Scrum|Previous Planned Issues|Product Epic Scrum Teams|Daily|M-F|
-|Integration Epic Teams Scrum|Previous Planned Issues|Integration Epic Scrum Teams|Daily|M-F|
-
-## External Team meetings
-
-|Title| Purpose |Attendees | Frequency|Days|
-|:---|:----- |:----------|:--------------|:-------------------|
-| P1 PM Tagup|Agenda driven P1 PM mtg|P1 PMs|Weekly|M|
-| P1 PM Tagup|Non-Agenda driven P1 PM mtg|P1 PMs|Weekly|F|
-| CSO/P1 Leads|Discuss xyz|P1 PMs|Bi-Weekly|F-A|
-| CSO/P1/C1/Other Leads|Discuss xyz|P1 PMs|Bi-Weekly|F-B|
-| P1 Daily|Discuss BB Current SOA|Daily crowd|Bi-Weekly|M-W2|
diff --git a/charter/Teams.md b/charter/Teams.md
deleted file mode 100644
index 1659a24c47b382d9e390e5960a65a49d65e0c1bc..0000000000000000000000000000000000000000
--- a/charter/Teams.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# Teams
-
-[[_TOC_]]
-
-## Engineering
-
-Big Bang consists of two primary missions: Product Development and Integration
-
-## Product Development
-
-Product development consists of improving Big Bang Applications used by all customers:
-
-* Upgrading application versions
-* Improving reliability
-* Adding configuration options used by multiple customers
-* Improving interface for customer consumption
-
-## Integration
-
-Integration consists of facilitating user adoption of Big Bang by providing:
-
-* On the ground debugging of production issues
-* Creation of Environment Bootstrap pipelines to test changes in versions of Big Bang Umbrella
-
-## Communication
-
-Execution in these two engineering efforts requires tight collaboration and feedback loop with each other and external teams as defined in the diagram below:
-
-
-
-### Product and Integration
-
-#### Product to Integration
-
-* Change logs
-* Tier 2/3 support for application specific issues in customer production environments
-
-#### Integration to Product
-
-* Bugs from customers that need to be solved in Big Bang Applications
-* Common "extensions" of Big Bang Umbrella that should be added to provide consistency across customers
-* Mock environments for Umbrella testing
-
-### Integration and Customers
-
-#### Integration To Customers
-
-* Changelog of new versions of Big Bang Umbrella
-* Building
-
-#### Customers to Integration
-
-* Bugs
-* Environment specifics that can go back into Mock Environments as defined in [Testing](Testing.md)
-
-### Product and Iron Bank
-
-#### Product to Iron Bank
-
-* Requests for new/updated Iron Bank Images
-* pipelines for testing Iron Bank Image functionality
-
-#### Iron Bank to Product
-
-* Approval of Iron Bank Images
diff --git a/charter/imgs/communication.png b/charter/imgs/communication.png
deleted file mode 100644
index a35665240a85583cd3b886ab6008e430837b77ff..0000000000000000000000000000000000000000
Binary files a/charter/imgs/communication.png and /dev/null differ
diff --git a/charter/imgs/product_epic_overlay.png b/charter/imgs/product_epic_overlay.png
deleted file mode 100644
index 2f161d9a40c900e7f77615b32819feb6cc87be1a..0000000000000000000000000000000000000000
Binary files a/charter/imgs/product_epic_overlay.png and /dev/null differ
diff --git a/charter/packages/README.md b/charter/packages/README.md
deleted file mode 100644
index dc8415ea9f4cdc2b503eb6c9f0f4982721a64601..0000000000000000000000000000000000000000
--- a/charter/packages/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# README
-
-All packages should have a folder under the `/packages` directory named `/packages/<name>` that contains all relevant information related to the Big Bang team assessment for inclusion into the Big Bang baseline
-
-**Do we maintain this information as packages are approved?**
diff --git a/docs/README.md b/docs/README.md
index ce3ed896c2be6679c904a9b5c4c9ca900f191ff1..f0270ce5a182bcd19588dd48d0fc6df84362f197 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -12,6 +12,38 @@
* [Release Notes](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/releases) lists the packages and their versions.
* For a code based source of truth, you can check [BigBang's default values.yaml](../chart/values.yaml), and `[CTRL] + [F]` "repo:", to quickly iterate through the list of applications supported by the BigBang team.
+
+### What BigBang isn't
+
+* BigBang by itself is not intended to be an End to End Secure Kubernetes Cluster Solution, but rather a reusable secure component/piece of a full solution.
+* A Secure Kubernetes Cluster Solution, will have multiple components, that can each be swappable and in some cases considered optional depending on use case and risk tolerance:
+ Example of some potential components in a full End to End Solution:
+ * P1's Cloud Native Access Point to protect Ingress Traffic. (This can be swapped with an equivalent, or considered optional in an internet disconnected setup.)
+ * Hardened Host OS
+ * Hardened Kubernetes Cluster (BigBang assumes ByoC, Bring your own Cluster) (The BigBang team recommends consumers who are interested in a full solution, partner with Vendors of Kubernetes Distributions to satisfy the prerequisite of a Hardened Kubernetes Cluster.)
+ * Hardened Applications running on the Cluster (BigBang helps solve this component)
+
+
+## Value add gained by using BigBang
+
+* Compliant with the [DoD DevSecOps Reference Architecture Design](https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf)
+* Can be used to check some but not all of the boxes needed to achieve a cATO (Continuous Authority to Operate.)
+* Uses hardened IronBank Container Images. (left shifted security concern)
+* GitOps adds security benefits, and BigBang leverages GitOps, and can be further extended using GitOps.
+ Security Benefits of GitOps:
+ * Prevents config drift between state of a live cluster and IaC/CaC source of truth: By avoiding giving any humans direct kubectl access, by only allowing humans to deploy via git commits, out of band changes are limited.
+ * Git Repo based deployments create an audit trail.
+ * Secure Configurations become reusable, which lowers the burden of implementing secure configurations.
+* Lowers maintainability overhead involved in keeping the images of the DevSecOps Platform's up to date and maintaining a secure posture over the long term. This is achieved by pairing the GitOps pattern with the Umbrella Helm Chart Pattern.
+ Let's walk through an example:
+ * Initially a kustomization.yaml file in a git repo will tell the Flux GitOps operator (software deployment bot running in the cluster), to deploy version 1.0.0 of BigBang. BigBang could deploy 10 helm charts. And each helm chart could deploy 10 images. (So BigBang is managing 100 container images in this example.)
+ * After a 2 week sprint version 1.1.0 of BigBang is released. A BigBang consumer updates the kustomization.yaml file in their git repo to point to version 1.1.0 of the BigBang Helm Chart. That triggers an update of 10 helm charts to a new version of the helm chart. Each updated helm chart will point to newer versions of the container images managed by the helm chart.
+ * So when the end user edits the version of 1 kustomization.yaml file, that triggers a chain reaction that updates 100 container images.
+ * These upgrades are pre-tested. The BigBang team "eats our own dogfood". Our CI jobs for developing the BigBang product, run against a BigBang dogfood Cluster, and as part of our release process we upgrade our dogfood cluster, before publishing each release. (Note: We don't test upgrades that skip multiple minor versions.)
+ * Auto updates are also possible by setting kustomization.yaml to 1.x.x, because BigBang follows semantic versioning, flux is smart enough to read x as the most recent version number.
+* DoD Software Developers get a Developer User Experience of "SSO for free". Instead of developers coding SSO support 10 times for 10 apps. The complexity of SSO support is baked into the platform, and after an Ops team correctly configures the Platform's SSO settings, SSO works for all apps hosted on the platform. The developer's user experience for enabling SSO for their app then becomes as simple as adding the label istio-injection=enabled (which transparently injects mTLS service mesh protection into their application's Kubernetes YAML manifest) and adding the label protect=keycloak to each pod, which leverages an EnvoyFilter CustomResource to auto inject an SSO Authentication Proxy in front of the data path to get to their application.
+
+
## How do I deploy BigBang?
**Note:** The Deployment Process and Pre-Requisites will vary depending on the deployment scenario. The [Quick Start Demo Deployment](guides/deployment-scenarios/quickstart.md) for example, allows some steps to be skipped due to a mixture of automation and generically reusable demo configuration that satisfies pre-requisites.
diff --git a/docs/airgap/README.md b/docs/airgap/README.md
deleted file mode 100644
index 8ac046b31b459af52146c62cd4581a664cd4b1a1..0000000000000000000000000000000000000000
--- a/docs/airgap/README.md
+++ /dev/null
@@ -1,520 +0,0 @@
-# Airgap
-
-Currently this is in proof of concept mode, so play around with this to get an idea of it.
-
-This work was quickly developed to entertain certain paths for image packaging and deployment.
-
-## Image Packaging / Deployment
-
-`package_images.sh` - Proof of concept script for image packaging
-
-* Dependencies
- * `docker` - The docker CLI tool
- * `images.txt` - A list of all requires airgap images
- * `jq` - The jq CLI tool
-* Deliverables
- * `registry:package.tar.gz` - Modified `registry:2` container loaded with airgap images
- * NOTE - `registry:2` vs `harbor` vs anything else is trivial, we can use whatever we want
- * Packaged images are loaded and retrievable immediately upon container start
- * `/var/lib/registry-package` is created and populated with images
- * `/etc/docker/registry/config.yml` is templated to use new registry folder
- * This is due to the fact that `/var/lib/registry` is a docker volume
-
-`deploy_images.sh` - Proof of concept script for image deployment
-
-* Dependencies
- * `docker` - The docker CLI tool
- * `registry:package.tar.gz` - Modified `registry:2` container loaded with airgap images
-* Deliverables
- * Running `registry` container with airgap images deployed and retrievable
-
-Hack commands:
-
-* `curl -sX GET http://localhost:5000/v2/_catalog | jq -r .`
- * Verify the catalog of a local running registry container
-
-## Repository Packaging / Deployment
-
-Airgap Deployment is a form of deployment which does not have any direct connection to the Internet or external network during cluster setup or runtime. During installation, bigbang requires certain images and git repositories for installation. Since we will be installing in internet-disconnected environment, we need to perform extra steps to make sure these resources are available.
-
-## Requirements and Prerequisites
-
-### General Prerequisites
-
-* A kubernetes cluster with container mirroring support. There is a section below that covers mirroring in more detail with examples for supported clusters.
-* BigBang(BB) [release artifacts](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/releases).
-* Utility Server.
-
-### Package Specific Prerequisites
-
-#### Elastic (Logging)
-
-Elastic requires a larger number of memory map areas than some OSes support by default. This can be change at startup with a cloud config or later using sysctl.
-
-```shell
-MIME-Version: 1.0
- Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
-
- --==MYBOUNDARY==
- Content-Type: text/x-shellscript; charset="us-ascii"
-
- #!/bin/bash
- # Set the vm.max_map_count to 262144.
- # Required for Elastic to run correctly without OOM errors.
- sysctl -w vm.max_map_count=262144
-```
-
-## Utility Server
-
-Utility Server is an internet-disconnected server that will host the private registry and git server that are required to deploy bigbang. It should include these command-line tools below;
-
-* `docker`: for running docker registry.
- * `registry:2` image
- * `openssl` for self-signed certificate.
-* `curl`: For troubleshooting registry.
-* `git`: for setup git server.
-
-## Git Server
-
-As part of BB release, we provide `repositories.tar.gz` which contains all the git repositories that BB depend on for deployment. You have two options for serving up these packages for Flux.
-
-### Option One
-
-You can follow the process below to setup git with `repositories.tar.gz` on the Utility Server.
-
-* Create Git user and SSH key
-
-```shell
-sudo useradd --create-home --shell /bin/bash git
-ssh-keygen -b 4096 -t rsa -f ~/.ssh/identity -q -N ""
-```
-
-* Create .SSH folder for `git` user
-
- ```shell
- sudo su - git
- mkdir -p .ssh && chmod 700 .ssh/
- touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
- exit
- ```
-
-* Add client ssh key to `git` user `authorized_keys`
-
- ```shell
- sudo su
- cat /[client-public-key-path]/identity.pub >> /home/git/.ssh/authorized_keys
- exit
- ```
-
-* Extract `repositories.tar.gz` to git user home directory
-
- ```shell
- sudo tar -xvf repositories.tar.gz --directory /home/git/
- ```
-
-* Add Hostname alias
-
- ```shell
- PRIVATEIP=$( curl http://169.254.169.254/latest/meta-data/local-ipv4 )
- sudo sed -i -e '1i'$PRIVATEIP' 'myhostname.com'\' /etc/hosts
- sudo sed -i -e '1i'$PRIVATEIP' 'host.k3d.internal'\' /etc/hosts #only for k3d
- ```
-
-* To test the client key;
-
- ```shell
- GIT_SSH_COMMAND='ssh -i /[client-private-key-path] -o IdentitiesOnly=yes' git clone git@[hostname/IP]:/home/git/repos/[sample-repo]
-
- #For example;
- GIT_SSH_COMMAND='ssh -i ~/.ssh/identity -o IdentitiesOnly=yes' git clone git@host.k3d.internal:/home/git/repos/bigbang
- #checkout release branch
- git checkout 1.3.0
- ```
-
-### Option Two
-
-There are some cases where you do not have access to or cannot create an ssh user on the utility server. It is possible to run an ssh git server on a non-standard port using Docker.
-
-* Create an SSH key
-
-```shell
-ssh-keygen -b 4096 -t rsa -f ./identity -q -N ""
-```
-
-* Extract `repositories.tar.gz` to your working directory
-
-```shell
-sudo tar -xvf repositories.tar.gz
-```
-
-* Start the provided Docker image (TODO: move this to an IB image when ready)
-
-```shell
-docker run -d -p 4001:22 -v ${PWD}/identity.pub:/home/git/.ssh/authorized_keys -v ${PWD}/repos:/home/git servicesengineering/gitshim:0.0.1
-```
-
-You will now be able to test by checking out some of the code.
-
-```shell
-GIT_SSH_COMMAND='ssh -i /[client-private-key-path] -o IdentitiesOnly=yes' git clone git@[hostname/IP]:[PORT]/home/git/repos/[sample-repo]
-
-# For example;
-GIT_SSH_COMMAND='ssh -i ~/.ssh/identity -o IdentitiesOnly=yes' git clone git@host.k3d.internal:[PORT]/home/git/repos/bigbang
-# Check out release branch
-git checkout 1.3.0
-```
-
-## Private Registry
-
-Images needed to run BB in your cluster is packaged as part of the release in `images.tar.gz`. You can see the list of required images in `images.txt`. In our airgap environment, we need to setup a registry that our cluster can pull required images from or an existing cluster where we can copy images from `images.tar.gz` into.
-
-### Set Up
-
-To setup the registry, we will be using `registry:2` to run a private registry with self-signed certificate.
-
-* First, untar `images.tar.gz`;
-
-```shell
-tar -xvf images.tar.gz -C .
-```
-
-* SCP `registry:2` tar file
-
-```shell
-docker save -o registry2.tar registry:2
-docker save -o k3s.tar rancher/k3s:v1.20.5-rc1-k3s1 #check release matching version
-scp registry2.tar k3s.tar ubuntu@hostname:~ #modify according to your environment
-docker load -i registry2.tar #on your registry server
-docker load -i k3s.tar
-```
-
-* Use the script [registry.sh](../assets/scripts/airgap-dev/registry.sh) to create registry;
-
-```shell
-$ chmod +x registry.sh && sudo ./registry.sh
-
-Required information:
-Enter bit size for certs (Ex. 4096): 4096
-Enter number of days to sign the certs with (Ex. 3650): 3650
-Enter the 'Country' for the cert (Ex. US): US
-Enter the 'State' for the cert (Ex. CO): CO
-Enter the 'Location' for the cert (Ex. ColoradoSprings): ColoradoSprings
-Enter the 'Organization' for the cert (Ex. PlatformOne): PlatformOne
-Enter the 'Organizational Unit' for the cert (Ex. Bigbang): BigBang
-Enter the 'Common Name' for the cert (Must be a FQDN (at least one period character) E.g. myregistry.com): myregistry.com
-Enter the 'Subject Alternative Name' for the cert(E.g. 1.2.3.4): 10.0.52.144
-
-Generating certs ...
-mkdir: cannot create directory ‘certs’: File exists
-Generating RSA private key, 4096 bit long modulus
-.............................................................................................................++
-.....................................++
-e is 65537 (0x10001)
-Generating RSA private key, 4096 bit long modulus
-......................................................................................................................++
-.......................++
-e is 65537 (0x10001)
-Signature ok
-subject=/C=US/ST=CO/L=ColoradoSprings/O=PlatformOne/CN=myregistry.com
-Getting CA Private Key
-
-Launching our private registry ...
-def21e7025c7d4ea7bbb30603955e0b7da14d077592851b327e59d78a849cb7d
-
-Installation finished ...
-
-Notes
-=====
-
-To see images in the registry;
-
-=========================
-curl https://myhostname.com:5443/v2/_catalog -k
-=========================
-```
-
-A folder is created with TLS certs that we are going to supply to our k8s cluster when pulling from the registry.
-
-You can ensure the images are now loaded in the registry;
-
-```shell
- curl -k https://myhostname.com:5443/v2/_catalog
-{"repositories":["ironbank/anchore/engine/engine","ironbank/anchore/enterprise/enterprise","ironbank/anchore/enterpriseui/enterpriseui","ironbank/big-bang/argocd","ironbank/bitnami/analytics/redis-exporter","ironbank/elastic/eck-operator/eck-operator","ironbank/elastic/elasticsearch/elasticsearch","ironbank/elastic/kibana/kibana","ironbank/fluxcd/helm-controller","ironbank/fluxcd/kustomize-controller","ironbank/fluxcd/notification-controller","ironbank/fluxcd/source-controller","ironbank/gitlab/gitlab/alpine-certificates","ironbank/gitlab/gitlab/cfssl-self-sign","ironbank/gitlab/gitlab/gitaly",...]
-```
-
-### Mirroring
-
-The images specified as part of the helm charts in BB are expected to be sourced from `registry1.dso.mil` hence this registry needs to be mirrored to the one setup above. To reduce the amount of work needed on the developer part, we will be taking advantage of container mirroring which is supported by `containerd` as well as `cri-o`. Check if your container runtime supports this as it is required for smooth developer experience when deploying BB. You should also check documentation on how your cluster supports passing these configuration to the runtime. For example, TKG and RKE2 support such configuration for `containerd` below to enable `registry.dso.mil` and `registry1.dso.mil` .
-
-​You need to also configure your cluster with appropriate registry TLS. Please consult your cluster documentation on how to configure this.
-
-If you need to handle mirroring manually, there is an example Ansible script provided that will update the containerd mirroring and restart the container runtimes for each node in your inventory. (copy-containerd-config.yaml)
-
-#### Konvoy Cluster
-
-Modify the `cluster.yaml` file and apply. More details can be found on the [D2iQ Konvoy documentation](https://docs.d2iq.com/dkp/konvoy/1.8/install/install-airgapped/).
-
-```yaml
-kind: ClusterConfiguration
-apiVersion: konvoy.mesosphere.io/v1beta2
-spec:
- imageRegistries:
- - server: https://registry1.dso.mil:443
- username: "myuser"
- password: "mypassword"
- default: true
- - server: https://registry.dso.mil:443
- username: "myuser"
- password: "mypassword"
- default: true
-```
-
-#### TKG Cluster
-
-```yaml
-...
- - path: /etc/containerd/config.toml
- content: |
- version = 2
- [plugins]
- [plugins."io.containerd.grpc.v1.cri"]
- sandbox_image = "registry.tkg.vmware.run/pause:3.2"
- [plugins."io.containerd.grpc.v1.cri".registry]
- [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
- [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry1.dso.mil"]
- endpoint = ["https://myregistry.com:5443"]
- [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.dso.mil"]
- endpoint = ["https://myregistry.com:5443"]
- ...
-```
-
-#### RKE2 cluster
-
-```yaml
-#registries.yaml
-mirrors:
- registry.dso.mil:
- endpoint:
- - https://myhostname.com:5443
- registry1.dso.mil:
- endpoint:
- - https://myhostname.com:5443
- registry1.dso.mil:
- endpoint:
- - https://myhostname.com:5443
-configs:
- myhostname.com:5443:
- tls:
- ca_file: "/etc/ssl/certs/registry1.pem"
-```
-
-## Installing Big Bang
-
-```shell
-cd bigbang
-```
-
-Install flux
-
-Install Flux 2 into the cluster using the provided artifacts. These are located in the scripts section of the Big Bang repository.
-
-```shell
-kubectl apply -f ./scripts/deploy/flux.yaml
-```
-
-After Flux is up and running you are ready to deploy Big Bang. We will do this using Helm. To first check to see if Flux is ready you can do.
-
-You can watch to see if Flux is reconciling the projects by watching the progress.
-
-```shell
-watch kubectl get all -n flux-system
-```
-
-We need a namespace for our preparations and eventually for Big Bang to deploy into.
-
-```shell
-kubectl create ns bigbang
-```
-
-Installing Big Bang in an air gap environment currently uses the Helm charts from the **[Big Bang Repo](https://repo1.dso.mil/platform-one/big-bang/bigbang)**.
-
-All changes are modified in the custom [values.yaml](../assets/scripts/airgap-dev/values.yaml) file. Modify as needed and replace IP.
-
-Change the hostname for the installation. It is currently set to the development domain:
-
-```yaml
-# -- Domain used for BigBang created exposed services, can be overridden by individual packages.
-hostname: bigbang.dev
-```
-
-Add your registry URL. This will be the IP address or URL of the utility server or the registry in which you have loaded all of the Big Bang images (note: it is possible that your registry doesn't have a username or password, there will be ignored for insecure registries.):
-
-```yaml
-# -- Single set of registry credentials used to pull all images deployed by BigBang.
-registryCredentials:
- registry: 10.0.52.144
- username: "asdfasdfasdf"
- password: "asdfasdfasdfasdfasdf"
- email: ""
-```
-
-For your Git repository you have two options for setting up the credentials.
-
-Option 1: Use an existing secret.
-
-```shell
-cd ~/.ssh
-ssh-keygen -b 4096 -t rsa -f ~/.ssh/identity -q -N ""
-ssh-keyscan <YOUR GIT URL HERE> ./known_hosts
-
-kubectl create secret generic -n bigbang ssh-credentials \
- --from-file=./identity \
- --from-file=./identity.pub \
- --from-file=./known_hosts
-```
-
-In the above example we created a new set of keys to use, you could also use an existing set of keys. These are just SSH keys, so any SSH key pair should work. The second command is going to create a known hosts file. There is no way to answer yes to the unknown hosts prompt, this alleviates that need.
-
-Once we have our private key, public key and the known hosts file, we place all of those into the secret using kubectl. This creates a BASE64 encoded secret of these values. !!! It is VERY important that the names of the files match above. So if you are using your own keypair change the names. Kubernetes uses the names of the files to create the keys inside of the secret.
-
-If you want to create your secret and store in the Kubernetes format you can add the -o yaml --dry-run to the above command to get that output.
-
-```shell
-kubectl create secret generic ssh-credentials \
- --from-file=./identity \
- --from-file=./identity.pub \
- --from-file=./known_hosts \
- -o yaml --dry-run
-```
-
-Once your secret is created you can add that value to the values.yaml that we were modifying above.
-
-```yaml
-git:
- # -- Existing secret to use for git credentials, must be in the appropriate format: https://toolkit.fluxcd.io/components/source/gitrepositories/#https-authentication
- existingSecret: "ssh-credentials"
-```
-
-** Note that we substituted the name of the secret from the example to the secret created above. This value is arbitrary, so if you created your secret with a different name use that name instead.
-
-Option 2: Put the values of your ssh keys directly in the values.yaml file.
-
-You can also elect to just put the key values and the known hosts directly into the chart's values.yaml file.
-
-```shell
-ssh-keygen -q -N "" -f ./identity
-ssh-keyscan <YOUR GIT URL HERE> ./known_hosts
-
-cat identity
-cat identity.pub
-cat known_hosts
-```
-
-Take the values from each of these files and place in the correct fields in the values.yaml.
-
-```yaml
-git:
- # -- SSH git credentials, privateKey, publicKey, and knownHosts must be provided
- privateKey: |
- -----BEGIN RSA PRIVATE KEY-----
- MIIEowIBAAKCAQEAwcG6YKsqDC6728XZ7/8oiqnQaw3OkQnvMBrzvZjxd//PsEog
- xVc+F9YqW4FIeTH57wN6JXIC4iMbE0QGd6+1yOoYiXkhi66tuO5FN+n4PeMnvKcC
- JXtFWme4W/9YnEk/3sbNOgAMPlhMhTsudzLiXtHd3g+xCmNs1pdEIInaNadrolWn
- QTM0krUCcC6VLCri7ae/pDloglX4cBJ+EfqFC94T6wUICPd1P7zYsy8WwIQtPhLT
- lbY8CHj9iMlxlUdwdiXTlifqHsPgTh3X5e9Vptd+wi0+vfjvrXd/8SuM1q8xdQvY
- bZ27AlhgfQsVl9WQrk/47xd3g430G4cqSbyhLQIDAQABAoIBAFlSu153akIFhXtz
- Ad7fbcxHLxs7WUCKKOevdTCyApgEqbWm5uazKqAIjqxytHuS65shqjz7C5M/Beti
- z+x7Z73BFiDCZBgmLNZ1mhmF1niJcTdKcvXel4FvEZHv7OTX7AcC9XfIr9xKDrTZ
- LLmtDqkR7UvDRiX44iMnxzOM+bkDsHVva00e3IoSiOsQ4DKQ1l/HFseVlPIaGzfZ
- Z2q0myUrBzlOYE06VJluhexsrrVDi7KdIfR8UGpN4kC5R/vOnOi7ycd4tfsZe2Wb
- CjbKMTNYRFnVTt6/SXAhhFu+kz0FftDXNTIOhikVB8ryZ5iyNXszYqiptUI9VUZB
- mQLdPuECgYEA9odVxlPUgSMLhbE5vD57jbtB6Cswy5ztAuyCHMABM4U6pVvFDSNb
- 244y0ov0TzviaCZkb+0qrAM0ZSNItLQ1PmbeD0SnB4q/C8hDvVtpB+0SPBJMX8so
- 49n1Wr5dH0axGMLaZXGmQ4DPEW/t0dNbYpN1Sxgn6KZPprISXigBufkCgYEAyTNe
- kY3vaJ6Nla1pBVUmiK7hu1G3Ddihy1w56upHbOnDvJySuVOM5HRPm2ISFwW38/b5
- 5+cGKWnmu7UhFi1d8Iz3Kmr6kpfRxEDtbrk5rkgKJmTtduxAzBH8CTZfxuYIC5xS
- 3fbcFpFYfrtE+3tjqlXJSOpLOuDqbA3uGwWFTdUCgYEAkSi9A8uGnAdDmJPzF/l+
- jMTPGOKdl7auBAO41S7lRi3Ti1xO2d6RDuVa3YiU8TakqIi6qQDwGFrGtiqhe+2E
- UFsHs9vLsfArb8eaw1uYq5c7HpHzsJASYp+LDcR7VpgsXRUWvZa+vI6S3oSWdu9J
- pvCGpxHxJdcPnWrKz/AknBkCgYAnej/U+W9/LJUFSFgx5qo/6Wh7M6ZiPh5I45it
- ojhPg3KXgHU9jco4TSYNi+mWwNV+NfiE6wyHdbMDI6ARVOd4uoAIv6M9NDLBeifc
- MNXDf3kWXXlGe0afg+va9uNGCH6NoKeVy8kVWIFvpFj9qxE8K8bp2qbWL6lveDA+
- 9w9X3QKBgGtkQi9OI7TyrloZ5F6/0/LnOJMGd/+e2cJUN6Pa10ZAjQh12JZ5fK7i
- Vwh5l0P5CGQsuC96n4xPELoBnbTdr+y17f0o+kAuSDAsXnDf/Jjr0y/+uzL6YYCg
- VD1yNitgcQw6oHKdTbGn4jni3/VemzONOz0uTB+/K7WhW2J7faaJ
- -----END RSA PRIVATE KEY-----
- publicKey: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBwbpgqyoMLrvbxdnv/yiKqdBrDc6RCe8wGvO9mPF3/+wSiDFVz4X1ipbgUh3MfnvA2olcgLiIxsTRAZ8r7XI6hiJeSGLrq2123kU36fg94ye8pwIle0VaZ7hb/1icST/exs06AAw+WEyFOy53MuJe0d3e$"
- knownHosts: "10.0.52.144 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPFZzQ6BmaswdhT8UWD5a/VYmZYrGv1qD3T+euf/gFjkPkeySYRIyM+Kg/UdHCHVBzc4aaFdBDmugHimZ4lbWpE="
-```
-
-** Note the above values are all examples and are intentionally not operational keys.
-
-Then install Big Bang using Helm.
-
-```shell
- helm upgrade -i bigbang chart -n bigbang --create-namespace -f values.yaml
- watch kubectl get gitrepositories,kustomizations,hr,po -A
-```
-
-** Note that the --create-namespace isn't needed if you created it earlier, but it doesn't hurt anything.
-
-You should see the different projects configure working through their reconciliation starting with "gatekeeper".
-
-## Using 3rd Party Packages
-
-The third party guide assumes that you already have or are planning to install Big Bang Core.
-
-### Package your Git repository
-
-Packaging your repository from Git
-
-```shell
-git clone --no-checkout https://repo1.dso.mil/platform-one/big-bang/apps/third-party/kafka.git && tar -zcvf kafka-repo.tar.gz kafka
-```
-
-This creates a tar of a full git repo without a checkout. After you have placed this git repo in its destination you can get the files to view by doing.
-
-```shell
-git checkout
-```
-
-### Package your registry images
-
-Package image
-
-```shell
-docker save -o image-name.tar image-name:image-version
-```
-
-Unpack the image on your utility server
-
-```shell
-tar -xvf image-name.tar
-```
-
-Move the image to the location of your other images.
-
-Restart your local registry and it should pick up the new image.
-
-```shell
-cd ./var/lib/registry
-docker run -p 25000:5000 -v $(pwd):/var/lib/registry registry:2
-# verify the registry mounted correctly
-curl http://localhost:25000/v2/_catalog -k
-# a list of Big Bang images should be displayed, if not check the volume mount of the registry
-```
-
-Configure `./synker.yaml`
-
-Example
-
-```yaml
-destination:
- registry:
- # Hostname of the destination registry to push to
- hostname: 10.0.0.10
- # Port of the destination registry to push to
- port: 5000
-```
-
-If you are using runtime mirroring the new image should be available at the original location on your cluster.
diff --git a/charter/diagrams/dev_ci_workflow.drawio b/docs/assets/diagrams/developer/dev_ci_workflow.drawio
similarity index 100%
rename from charter/diagrams/dev_ci_workflow.drawio
rename to docs/assets/diagrams/developer/dev_ci_workflow.drawio
diff --git a/charter/imgs/dev_ci_workflow.png b/docs/assets/imgs/developer/dev_ci_workflow.png
similarity index 100%
rename from charter/imgs/dev_ci_workflow.png
rename to docs/assets/imgs/developer/dev_ci_workflow.png
diff --git a/docs/developer/README.md b/docs/developer/README.md
index aa0a693c68ff39b8eb9effe4dd697e06b9b8dc68..4098f7f4cffecd27d500a785eb452a424c9ed99e 100644
--- a/docs/developer/README.md
+++ b/docs/developer/README.md
@@ -2,25 +2,24 @@
[[_TOC_]]
-## Charter
+## Preface
-The [BigBang Charter](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/tree/master/charter) is required reading for BigBang developers. Study all the documents carefully before you start developing. The Charter lays out the policies, requirements, and responsibilities for the BigBang product and the supported Packages (applications). At a high level, the BigBang product is a helm chart that wraps the deployment of DevSecOps applications (Packages). The goal of BigBang is to hide the complexity of deploying and integrating the supported Packages. Customers should be able to easily deploy and configure a DevSecOps environment. BigBang is intended to deploy on any OCI/CNCF compliant Kubernetes cluster.
+Please read through the documentation linked here and in the [understanding big bang folder](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/tree/master/docs/understanding_bigbang) to understand Big Bang concepts and development standards. Study all the documents carefully before you start developing.Â
## Communications
-Join Mattermost channels to ask questions and communicate with the team. The team also has a daily Scrum at 8:15 am MST. The link for the stand up is found on the [Big Bang Group Calendar](https://confluence.il2.dso.mil/display/BB1/calendar/dfb757d4-110c-4aac-80d8-516fd2d0cea8?calendarName=Big%20Bang%20Group%20Calendar). Here is the list of relevant Mattermost channels for BigBang development:
+Join MatterMost channels to ask questions and communicate with the team. Here is the list of relevant Mattermost channels for BigBang development:
* [Value Stream - Big Bang](https://chat.il2.dso.mil/platform-one/channels/team---big-bang)
* [Topic - Big Bang Documentation](https://chat.il2.dso.mil/platform-one/channels/topic-big-bang-documentation)
-## Big Bang Framework
-
-Big Bang is a helm chart of helm charts. Big Bang uses [Flux 2](https://fluxcd.io/) to deploy [Helm](https://helm.sh/) charts. The Helm charts that are deployed by BigBang are called Packages. The [Package repositories](https://repo1.dso.mil/platform-one/big-bang/apps) are organized into groups such as core, security tools, developer tools, collaboration tools, etc.
-
## Set up a development environment
[Development Environment](./development-environment.md)
+## Package Requirements
+[Big Bang Package Requirements](./PackageRequirements.md)
+
## Package Development
[Develop a Big Bang Package](./develop-package.md)
@@ -29,6 +28,9 @@ Big Bang is a helm chart of helm charts. Big Bang uses [Flux 2](https://fluxcd.i
[Integrate Package with Big Bang](./package-integration/README.md)
+## Package Owner Overview
+[Package Owner Requirements & Overview](./PackageOwner.md)
+
## Big Bang Code Through Party Bus Pipeline
[Code Through Party Bus MDO Pipeline](./mdo-partybus-pipelines.md)
diff --git a/charter/ReleaseProcess.md b/docs/developer/ReleaseProcess.md
similarity index 100%
rename from charter/ReleaseProcess.md
rename to docs/developer/ReleaseProcess.md
diff --git a/charter/Testing.md b/docs/developer/Testing.md
similarity index 100%
rename from charter/Testing.md
rename to docs/developer/Testing.md
diff --git a/charter/VendorDistroIntegration.md b/docs/developer/VendorDistroIntegration.md
similarity index 100%
rename from charter/VendorDistroIntegration.md
rename to docs/developer/VendorDistroIntegration.md
diff --git a/docs/k8s-storage.md b/docs/developer/k8s-storage.md
similarity index 100%
rename from docs/k8s-storage.md
rename to docs/developer/k8s-storage.md
diff --git a/charter/HelmStandards.md b/docs/developer/package-integration/package-integration-helm_standards.md
similarity index 97%
rename from charter/HelmStandards.md
rename to docs/developer/package-integration/package-integration-helm_standards.md
index 6a1e2b90c688147a32cf45813d2faa23bd0f7e0d..600fdc202b0418b32c67ed4819d673e7604faa81 100644
--- a/charter/HelmStandards.md
+++ b/docs/developer/package-integration/package-integration-helm_standards.md
@@ -1,6 +1,6 @@
# Helm Package Standards
-This document describes the technical standards that should be in place when building a Helm chart and integrating it with BigBang
+This document describes the technical guidelines that should be in place when building a Helm chart and integrating it with BigBang.
## Helm Package Versioning Scheme
diff --git a/charter/PackageOwner.md b/docs/developer/package-integration/package-integration-ownership.md
similarity index 94%
rename from charter/PackageOwner.md
rename to docs/developer/package-integration/package-integration-ownership.md
index bba333796f3a3cb47412854c6ac6098cc1edd088..c94c6e64eefde3adff110219de4aac41d56dc330 100644
--- a/charter/PackageOwner.md
+++ b/docs/developer/package-integration/package-integration-ownership.md
@@ -3,7 +3,7 @@
Package owners will be responsible for the following:
* Cutting Releases for the packages and getting into BigBang
-* Implementing Package requirements outlined by [Package Requirements](PackageRequirements.md)
+* Implementing Package requirements outlined by the [package integration guide](../package-integration.md)
* Reviewing Merge Requests into the Package Repository
* Reviewing Merge Request CI/CD pipeline execution results to ensure that there are no regressions in conformance tests nor package cypress tests.
* Tracking upstream changes to packages including new features, architectures, dependencies.
diff --git a/docs/developer/package-integration/pipeline.md b/docs/developer/package-integration/pipeline.md
index 731bbfb1370754824b737be6a69640b7bb8bf0ee..9dd52953dba467515162ff9a481bec7912283a56 100644
--- a/docs/developer/package-integration/pipeline.md
+++ b/docs/developer/package-integration/pipeline.md
@@ -11,6 +11,11 @@ Big Bang contains and uses a continuous deployment tool to deploy packages using
> Throughout this document, we will be setting up an application called `podinfo` as a demonstration.
+
+## Branching
+
+Each package will have a default branch of `main`. Immutable tags will be used to identify releases and will follow a semver versioning scheme.
+
## Package Pipeline
Pipelines provide rapid feedback to changes in our Helm chart as we develop and should be put in place as early as possible. Big Bang has a few different pipelines that can be used for packages.
diff --git a/docs/guides/README.md b/docs/guides/README.md
deleted file mode 100644
index f3c68fe108ca94e3d2b72b83914f57143d622afd..0000000000000000000000000000000000000000
--- a/docs/guides/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Guides
-
-## backups-and-migrations
-
-Guides on handling backups/migrations using Velero for specific Big Bang packages.
-
-## deployment_scenarios
-
-Beginner friendly how to guides are intended to be added to these subfolders over time.
-
-## prerequisites
-
-Beginner friendly comprehensive explanations of prerequisites that are generically applicable to multiple scenarios
-
-## using_bigbang
-
-Beginner friendly information on how to use Big Bang, intended to encompass how to navigate and work with BB packages
diff --git a/docs/airgap/k3d.md b/docs/guides/airgap/k3d.md
similarity index 100%
rename from docs/airgap/k3d.md
rename to docs/guides/airgap/k3d.md
diff --git a/docs/airgap/pipeline.md b/docs/guides/airgap/pipeline.md
similarity index 100%
rename from docs/airgap/pipeline.md
rename to docs/guides/airgap/pipeline.md
diff --git a/docs/airgap/synker.md b/docs/guides/airgap/synker.md
similarity index 100%
rename from docs/airgap/synker.md
rename to docs/guides/airgap/synker.md
diff --git a/docs/guides/gitlab-backup-restore.md b/docs/guides/backup-and-restore/gitlab-backup-restore.md
similarity index 100%
rename from docs/guides/gitlab-backup-restore.md
rename to docs/guides/backup-and-restore/gitlab-backup-restore.md
diff --git a/docs/guides/nexus-migration-with-velero.md b/docs/guides/backup-and-restore/nexus-migration-with-velero.md
similarity index 100%
rename from docs/guides/nexus-migration-with-velero.md
rename to docs/guides/backup-and-restore/nexus-migration-with-velero.md
diff --git a/docs/guides/prerequisites/README.md b/docs/guides/prerequisites/README.md
deleted file mode 100644
index cd548b5254dac40cecc64f3e4b3fcba4337ab683..0000000000000000000000000000000000000000
--- a/docs/guides/prerequisites/README.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Prerequisites:
-
-- How the Prerequisites docs are organized:
- - This README.md is meant to be a high level overview of prerequsites.
- - /docs/guides/prerequsites/(some_topic).md files are meant to offer more specific guidance on prerequisites while staying generic.
- - The /docs/guides/deployment_scenarios/(some_topic).md files may also offer additional details on prerequesites specific to the scenario.
-- Prerequisites vary depending on deployment scenario, thus a table is used to give an overview.
-- Note for future edits: The following table was generated using tablesgenerator.com/markdown_tables, recommended to copy the table's raw text contents, visit tablesgenerator.com/markdown_tables, and File -> Paste table data when edits are needed.
-
-| Prerequisites(rows) vs Deployment Scenarios(columns) | QuickStart | Internet Connected | Internet Disconnected |
-| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **[Minimum Hardware Requirements](minimum-hardware-requirements.md)** (vCPU, Memory, and Disk Storage for Big Bang in a production system) | The quickstart's demo values are known to work against a single VM with 8 CPU cores, 32 GB ram, and a 100 GB root partition. (It should be possible to lower the helm values to fit on 4 CPU cores and 16 GB ram, and less disk space.) | Appropriately sized CSP instances (The hardware requirements vary greatly depending on the enabled packages, internal database use, replicas, nodes, and memory/cpu requests.) | Appropriately sized virtual or bare metal machines (The hardware requirements vary greatly depending on the enabled packages, internal database use, replicas, nodes, and memory/cpu requests.) |
-| **[OS Preconfigured](os-preconfiguration.md) and Prehardened** (OS and level of hardening required depends on AO) | Prerequisite Recommended: A non-hardened single VM, (the quickstart has copy pasteable commands to satisfy the configuration requirements.) | Prerequisite (CSPs usually have marketplaces with pre-hardened VM images) | Prerequisite (configured to AO's risk tolerance / mission needs) |
-| **[Kubernetes Distribution Preconfigured](kubernetes-preconfiguration.md) to Best Practices and Prehardened** (Any CNCF Kubernetes Distribution will work as long as an AO signs off on it) | k3d is recommended for demos (It can be quickly installed and setup using copy pasteable commands in the quickstart, ships with a dockerized LB, works on every cloud, and bare metal) | Prerequisite (https://repo1.dso.mil/platform-one/distros) | Prerequisite (users are responsible for airgap image import of container images needed by chosen Kubernetes Distribution) |
-| **Default Storage Class** ((for Dynamic PVCs), the SC needs to support RWX (Read Write Many) Access Mode to support HA deployment of all BigBang AddOns) | Presatisfied* (*if using k3d, which has dynamic local volume storage class baked in) | Prerequisite It's recommended that users start with a CSP specific or Kubernetes Distro provided storage class | Prerequisite [(These docs compare Cloud Agnostic Storage Solutions)](../../k8s-storage.md#kubernetes-storage-options) |
-| **Support for Automated Provisioning of Service Type Load Balancer** (is recommended) | Presatisfied* (*if using k3d, which ships with the ability to add flags to treat the VM's port 443 as Kubernetes Service of Type LB's port 443, automation in the quick start repo leverages these flags) | Prerequisite Kubernetes Distributions usually have CSPs specific flags you can pass to the kube-apiserver to support auto provisioning of CSP LBs. | Prerequisite [(See docs for guidance on bare metal and no IAM scenarios)](kubernetes-preconfiguration.md#service-of-type-load-balancer) |
-| **Access to Container Images** (IronBank Image Pull Credentials or AirGap import from .tar.gz's) | Prerequisite (Anyone can go to login.dso.mil, and self register against P1's SSO. That can be used to login to registry1.dso.mil to generate image pull credentials for the QuickStart) | BigBang customers are recommended to use ask their BB Customer Liaison's for an IronBank Image pull robot account, which lasts 6 months. | Prerequisite (Airgap import of container images, [BigBang Releases](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/releases) includes a .tar.gz of IronBank Images) |
-| **Customer Controlled Private Git Repo** (for GitOps, the Cluster needs network access & Credentials for Read Access to said Git Repo) | Substituted (the turn key demo uses a non GitOps workflow ) | Prerequisite (or follow Air gap docs) | Prerequisite (Air gap docs assist with provisioning an ssh based git repo) |
-| **Encrypt Secrets as Code** (Use SOPS + CSP KMS or PGP to encrypt secrets that need to be stored in the GitRepo) | Substituted (Quickstart demo leverages clear text secrets in local files / outside of git) | Prerequisite (CSP KMS and IAM is more secure that gpg key pair) | Prerequisite (Use CSP KMS if available, PGP works universally, [Flux requires the private PGP key to not have a passphrase](https://toolkit.fluxcd.io/guides/mozilla-sops/#generate-a-gpg-key)) |
-| **Install and Configure Flux** (Flux needs Git Repo Credentials & CSP IAM rights for KMS decryption or a kubernetes secret containing a private PGP decryption key) | Presatisfied (Quickstart demo only needs installation not configuration) | Prerequisite (see BigBang docs, [flux docs](https://toolkit.fluxcd.io/components/source/gitrepositories/#spec-examples) are also a good resource for this) | Prerequisite (see BigBang docs) |
-| **HTTPS Certificates** | Presatisfied (The quickstart deploys \*.bigbang.dev HTTPS Certificate, from the bigbang repo, a non-expired cleartext copy of the cert is kept there for dev/demo purposes, alternatively mkcert can be used to generate demo certs for arbitrary DNS names that will only be trusted by the laptop that provisioned the mkcert cert) | Prerequisite (HTTPS cert is provided by consumer) | Prerequisite (HTTPS cert is provided by consumer) |
-| **DNS** | Edit your Laptop's host file (/etc/hosts, C:\Windows\System32\drivers\etc\hosts), or use something like AWS VPC Private DNS and [sshuttle](https://github.com/sshuttle/sshuttle) to point to host VM (if using k3d) | Prerequisite (point DNS names to Layer 4 CSP LB) | Prerequisite (point DNS names to L4 LB) |
-| **HTTPS Certificate, DNS Name, and hostnames in BigBang's helm values must match** (in order for Ingress to work correctly.) | QuickStart leverages `*.bigbang.dev` HTTPS cert, and the BigBang Helm Chart's values.yaml's hostname defaults to bigbang.dev, just need to ensure multiple hostfile entries like "grafana.bigbang.dev " exist, or if you have access to DNS a wildcard entry to map CNAME `*.bigbang.dev` to k3d VM's IP | Prerequisite (update bigbang helm values in git repo so hostnames match HTTPS cert) | Prerequisite (update bigbang helm values in git repo so hostnames match HTTPS cert) |
-| **SSO Identity Provider** (Prerequisite for SSO Authentication Proxy feature) | Presatisfied* (*depending on which quick start config is used), There's exists a demo SSO config that leverages P1's CAC enabled SSO, it's coded to only work for localhost to balance turn key demo functionality against security concerns. | Prerequisite (You don't have to use Keycloak, you can use any OIDC/SAML Identity Provider) | Prerequisite* (Install your own Keycloak cluster), leverage a pre-existing airgap SSO solution, or configure to not use SSO* if not needed for the use case) |
-| **Ops Team to integrate, configure, and maintain BigBang** (needed skillsets: DevOps IaC/CaC all the things, automate most the things, document the rest, linux administration, productionalization and maintenance of a Kubernetes Cluster.) | QuickStart Demo is designed to be self service. | Prerequisite (BigBang Customer Integration Engineers are available to help long term Ops teams.) | Prerequisite |
diff --git a/docs/guides/prerequisites/default-storageclass.md b/docs/prerequisites/default-storageclass.md
similarity index 100%
rename from docs/guides/prerequisites/default-storageclass.md
rename to docs/prerequisites/default-storageclass.md
diff --git a/docs/guides/prerequisites/install-flux.md b/docs/prerequisites/install-flux.md
similarity index 100%
rename from docs/guides/prerequisites/install-flux.md
rename to docs/prerequisites/install-flux.md
diff --git a/docs/guides/prerequisites/kubernetes-preconfiguration.md b/docs/prerequisites/kubernetes-preconfiguration.md
similarity index 100%
rename from docs/guides/prerequisites/kubernetes-preconfiguration.md
rename to docs/prerequisites/kubernetes-preconfiguration.md
diff --git a/docs/guides/prerequisites/minimum-hardware-requirements.md b/docs/prerequisites/minimum-hardware-requirements.md
similarity index 100%
rename from docs/guides/prerequisites/minimum-hardware-requirements.md
rename to docs/prerequisites/minimum-hardware-requirements.md
diff --git a/docs/guides/prerequisites/minimum-hardware-requirements.xlsx b/docs/prerequisites/minimum-hardware-requirements.xlsx
similarity index 100%
rename from docs/guides/prerequisites/minimum-hardware-requirements.xlsx
rename to docs/prerequisites/minimum-hardware-requirements.xlsx
diff --git a/docs/guides/prerequisites/os-preconfiguration.md b/docs/prerequisites/os-preconfiguration.md
similarity index 100%
rename from docs/guides/prerequisites/os-preconfiguration.md
rename to docs/prerequisites/os-preconfiguration.md
diff --git a/docs/guides/prerequisites/pod-usage-in-grafana.md b/docs/prerequisites/pod-usage-in-grafana.md
similarity index 100%
rename from docs/guides/prerequisites/pod-usage-in-grafana.md
rename to docs/prerequisites/pod-usage-in-grafana.md
diff --git a/docs/understanding-bigbang/kube-apiserver-webhooks-diagram.md b/docs/understanding-bigbang/architecture-diagrams/kube-apiserver-webhooks-diagram.md
similarity index 100%
rename from docs/understanding-bigbang/kube-apiserver-webhooks-diagram.md
rename to docs/understanding-bigbang/architecture-diagrams/kube-apiserver-webhooks-diagram.md
diff --git a/docs/understanding-bigbang/logs-data-flow-diagram.md b/docs/understanding-bigbang/architecture-diagrams/logs-data-flow-diagram.md
similarity index 100%
rename from docs/understanding-bigbang/logs-data-flow-diagram.md
rename to docs/understanding-bigbang/architecture-diagrams/logs-data-flow-diagram.md
diff --git a/docs/understanding-bigbang/metrics-data-flow-diagram.md b/docs/understanding-bigbang/architecture-diagrams/metrics-data-flow-diagram.md
similarity index 100%
rename from docs/understanding-bigbang/metrics-data-flow-diagram.md
rename to docs/understanding-bigbang/architecture-diagrams/metrics-data-flow-diagram.md
diff --git a/docs/understanding-bigbang/network-encryption-and-ingress-diagram.md b/docs/understanding-bigbang/architecture-diagrams/network-encryption-and-ingress-diagram.md
similarity index 100%
rename from docs/understanding-bigbang/network-encryption-and-ingress-diagram.md
rename to docs/understanding-bigbang/architecture-diagrams/network-encryption-and-ingress-diagram.md
diff --git a/charter/GitOpsEngine.md b/docs/understanding-bigbang/concepts/GitOpsEngine.md
similarity index 100%
rename from charter/GitOpsEngine.md
rename to docs/understanding-bigbang/concepts/GitOpsEngine.md
diff --git a/docs/deployment.md b/docs/understanding-bigbang/concepts/deployment.md
similarity index 100%
rename from docs/deployment.md
rename to docs/understanding-bigbang/concepts/deployment.md
diff --git a/docs/encryption.md b/docs/understanding-bigbang/concepts/encryption.md
similarity index 100%
rename from docs/encryption.md
rename to docs/understanding-bigbang/concepts/encryption.md
diff --git a/docs/overview.md b/docs/understanding-bigbang/concepts/glossary.md
similarity index 100%
rename from docs/overview.md
rename to docs/understanding-bigbang/concepts/glossary.md
diff --git a/docs/troubleshooting.md b/docs/understanding-bigbang/concepts/troubleshooting.md
similarity index 100%
rename from docs/troubleshooting.md
rename to docs/understanding-bigbang/concepts/troubleshooting.md
diff --git a/docs/understanding-bigbang/configuration/base_config.md b/docs/understanding-bigbang/configuration/base_config.md
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/configuration.md b/docs/understanding-bigbang/configuration/configuration.md
similarity index 100%
rename from docs/configuration.md
rename to docs/understanding-bigbang/configuration/configuration.md
diff --git a/docs/postrenderers.md b/docs/understanding-bigbang/configuration/postrenderers.md
similarity index 90%
rename from docs/postrenderers.md
rename to docs/understanding-bigbang/configuration/postrenderers.md
index e536fa92e14766c77cddbfdb24fe252b124990a1..c6be3e47364ba2f2bb20c92ddf17d4c312324e1d 100644
--- a/docs/postrenderers.md
+++ b/docs/understanding-bigbang/configuration/postrenderers.md
@@ -1,5 +1,7 @@
# Post Renderers
+Post rendering gives chart installers the ability to manually manipulate, configure, and/or validate rendered manifests before they are installed by Helm.
+
[Flux V2](https://toolkit.fluxcd.io/) provides the ability to apply kustomizations on a Helm Release after rendering using a [Post Renderer](https://toolkit.fluxcd.io/components/helm/helmreleases/#post-renderers). This feature provides significant flexibility to the Helm objects, and allows for adjusting values inside of Helm that are not exposed explicitly as part of the values file. Each `HelmRelease` is configured with a `postRenderer` pass through:
```yaml
diff --git a/docs/production.md b/docs/understanding-bigbang/configuration/sample_prod_config.md
similarity index 100%
rename from docs/production.md
rename to docs/understanding-bigbang/configuration/sample_prod_config.md
diff --git a/docs/understanding-bigbang/licensing-expectations.md b/docs/understanding-bigbang/licensing-model.md
similarity index 99%
rename from docs/understanding-bigbang/licensing-expectations.md
rename to docs/understanding-bigbang/licensing-model.md
index 7e5d038e6683ab2911daf7cfd7094dacbad23eac..1ca3ffd5d6ec85299610f94cbb17cd149c0a2a01 100644
--- a/docs/understanding-bigbang/licensing-expectations.md
+++ b/docs/understanding-bigbang/licensing-model.md
@@ -1,4 +1,4 @@
-# BigBang Licensing Expectations
+# BigBang Licensing Model Overview
While BigBang is open source and free to use, the same cannot be said of its components. The licensing requirements of components requires a nuanced explanation. The intent of this document is to be a self service resource to help consumers of BigBang make an informed decision regarding licenses they may need to successfully deploy an ATO'able DevSecOps Platform using BigBang.
diff --git a/charter/BigBangPackages.md b/docs/understanding-bigbang/package-architecture/README.md
similarity index 100%
rename from charter/BigBangPackages.md
rename to docs/understanding-bigbang/package-architecture/README.md
diff --git a/charter/packages/anchore/Architecture.md b/docs/understanding-bigbang/package-architecture/anchore/Architecture.md
similarity index 100%
rename from charter/packages/anchore/Architecture.md
rename to docs/understanding-bigbang/package-architecture/anchore/Architecture.md
diff --git a/charter/packages/authservice/Architecture.md b/docs/understanding-bigbang/package-architecture/authservice/Architecture.md
similarity index 100%
rename from charter/packages/authservice/Architecture.md
rename to docs/understanding-bigbang/package-architecture/authservice/Architecture.md
diff --git a/charter/packages/cluster-auditor/Architecture.md b/docs/understanding-bigbang/package-architecture/cluster-auditor/Architecture.md
similarity index 100%
rename from charter/packages/cluster-auditor/Architecture.md
rename to docs/understanding-bigbang/package-architecture/cluster-auditor/Architecture.md
diff --git a/charter/packages/elasticsearch-kibana/Architecture.md b/docs/understanding-bigbang/package-architecture/elasticsearch-kibana/Architecture.md
similarity index 100%
rename from charter/packages/elasticsearch-kibana/Architecture.md
rename to docs/understanding-bigbang/package-architecture/elasticsearch-kibana/Architecture.md
diff --git a/charter/packages/fluentbit/Architecture.md b/docs/understanding-bigbang/package-architecture/fluentbit/Architecture.md
similarity index 100%
rename from charter/packages/fluentbit/Architecture.md
rename to docs/understanding-bigbang/package-architecture/fluentbit/Architecture.md
diff --git a/charter/packages/gitlab/Architecture.md b/docs/understanding-bigbang/package-architecture/gitlab/Architecture.md
similarity index 100%
rename from charter/packages/gitlab/Architecture.md
rename to docs/understanding-bigbang/package-architecture/gitlab/Architecture.md
diff --git a/charter/packages/istio/Architecture.md b/docs/understanding-bigbang/package-architecture/istio/Architecture.md
similarity index 100%
rename from charter/packages/istio/Architecture.md
rename to docs/understanding-bigbang/package-architecture/istio/Architecture.md
diff --git a/charter/packages/jaeger/Architecture.md b/docs/understanding-bigbang/package-architecture/jaeger/Architecture.md
similarity index 100%
rename from charter/packages/jaeger/Architecture.md
rename to docs/understanding-bigbang/package-architecture/jaeger/Architecture.md
diff --git a/charter/packages/keycloak/Architecture.md b/docs/understanding-bigbang/package-architecture/keycloak/Architecture.md
similarity index 100%
rename from charter/packages/keycloak/Architecture.md
rename to docs/understanding-bigbang/package-architecture/keycloak/Architecture.md
diff --git a/charter/packages/kiali/Architecture.md b/docs/understanding-bigbang/package-architecture/kiali/Architecture.md
similarity index 100%
rename from charter/packages/kiali/Architecture.md
rename to docs/understanding-bigbang/package-architecture/kiali/Architecture.md
diff --git a/charter/packages/kyverno/Architecture.md b/docs/understanding-bigbang/package-architecture/kyverno/Architecture.md
similarity index 100%
rename from charter/packages/kyverno/Architecture.md
rename to docs/understanding-bigbang/package-architecture/kyverno/Architecture.md
diff --git a/charter/packages/loki/Architecture.md b/docs/understanding-bigbang/package-architecture/loki/Architecture.md
similarity index 100%
rename from charter/packages/loki/Architecture.md
rename to docs/understanding-bigbang/package-architecture/loki/Architecture.md
diff --git a/charter/packages/mattermost/Architecture.md b/docs/understanding-bigbang/package-architecture/mattermost/Architecture.md
similarity index 100%
rename from charter/packages/mattermost/Architecture.md
rename to docs/understanding-bigbang/package-architecture/mattermost/Architecture.md
diff --git a/charter/packages/minio/Architecture.md b/docs/understanding-bigbang/package-architecture/minio/Architecture.md
similarity index 100%
rename from charter/packages/minio/Architecture.md
rename to docs/understanding-bigbang/package-architecture/minio/Architecture.md
diff --git a/charter/packages/monitoring/Architecture.md b/docs/understanding-bigbang/package-architecture/monitoring/Architecture.md
similarity index 100%
rename from charter/packages/monitoring/Architecture.md
rename to docs/understanding-bigbang/package-architecture/monitoring/Architecture.md
diff --git a/charter/packages/opa-gatekeeper/Architecture.md b/docs/understanding-bigbang/package-architecture/opa-gatekeeper/Architecture.md
similarity index 100%
rename from charter/packages/opa-gatekeeper/Architecture.md
rename to docs/understanding-bigbang/package-architecture/opa-gatekeeper/Architecture.md
diff --git a/charter/packages/ref-package/Architecture.md b/docs/understanding-bigbang/package-architecture/ref-package/Architecture.md
similarity index 100%
rename from charter/packages/ref-package/Architecture.md
rename to docs/understanding-bigbang/package-architecture/ref-package/Architecture.md
diff --git a/charter/packages/sonarqube/Architecture.md b/docs/understanding-bigbang/package-architecture/sonarqube/Architecture.md
similarity index 100%
rename from charter/packages/sonarqube/Architecture.md
rename to docs/understanding-bigbang/package-architecture/sonarqube/Architecture.md
diff --git a/charter/packages/twistlock/Architecture.md b/docs/understanding-bigbang/package-architecture/twistlock/Architecture.md
similarity index 100%
rename from charter/packages/twistlock/Architecture.md
rename to docs/understanding-bigbang/package-architecture/twistlock/Architecture.md