Merge branch '925-links' into 'master'

Docs - 925 - Fix broken links and references in Bigbang documentation

Closes #925

See merge request platform-one/big-bang/bigbang!1087

CODEOWNERS

@@ -7,7 +7,6 @@
 /base/                          @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /chart/                         @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /charter/                       @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
-/hack/                          @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /scripts/                       @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /tests/                         @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /docs/                          @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
@@ -32,7 +31,6 @@ tests/                          @toladipupo @brandencobb @evan.rush
 
 ^[Hack Owners]
 scripts/                        @toladipupo @michaelmcleroy @egoode
-hack/                           @toladipupo @michaelmcleroy @egoode
 
 ^[Charter Owners]
 charter/                        @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb

CONTRIBUTING.md

@@ -53,17 +53,17 @@ Configure `myvalues.yaml` to suit your needs.
 # Deploy the latest fluxv2 with Iron Bank images
 # For development, you can use flux from the internet using 'flux install`
 # Be aware, the internet version is likely newer than the Iron Bank version
-./hack/flux-install.sh
+./scripts/install_flux.sh
 
 # Apply a local version of the Big Bang chart
 # NOTE: This is the alternative to deploying a HelmRelease and having flux manage it, we use a local copy to avoid having to commit every change
 helm upgrade -i bigbang chart -n bigbang --create-namespace -f myvalues.yaml
 
-# It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the flux `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the ./hack/sync.sh script.
-./hack/sync.sh
+# It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the flux `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the ./scripts/sync.sh script.
+./scripts/sync.sh
 ```
 
-For more extensive development, use the [Development Guide](docs/c_development.md).
+For more extensive development, use the [Development Guide](./docs/developer).
 
 ## Testing Big Bang Development Changes
 
@@ -81,15 +81,11 @@ All routable endpoints BigBang deploys will use the TLD of `bigbang.dev` by defa
 
 ## Secrets & Certificates
 
-A __development only__ gpg key is provided at `bigbang-dev.asc` that is used to encrypt and decrypt the secrets in this Git repository (e.g. [hack/secrets](hack/secrets/).
-
-We cannot stress enough, __do not use this key to encrypt real secret data__.  It is a shared key meant to demonstrate the workflow of secrets management within Big Bang.
-
-Follow instructions in the [Big Bang encryption guide](docs/3_encryption.md) for how to encrypt and decrypt secrets.
+Follow instructions in the [Big Bang encryption guide](./docs/encryption.md) for how to encrypt and decrypt secrets.
 
 ## Merge requests process
 
 The merge request process is provided as an overview of the pipeline stages required to get a commit merged.
 
-Follow instruction in [CI-Workflow](docs/developer/ci-workflow.md) for specific details on the pipeline stages.
+Follow instruction in [CI-Workflow](./docs/developer/ci-workflow.md) for specific details on the pipeline stages.
 

README.md

@@ -14,11 +14,11 @@ Big Bang follows a [GitOps](#gitops) approach to configuration management, using
 
 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 Overview](./docs/1_overview.md).
+Additional information can be found in [Big Bang Overview](./docs/overview.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.  Follow the instructions in [Big Bang Getting Started](./docs/2_getting_started.md) to customize and deploy Big Bang.
+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.  Follow the instructions in [Big Bang Getting Started](./docs) to customize and deploy Big Bang.
 
 ## Maintainers
 
@@ -52,7 +52,7 @@ To start using Big Bang, you will need to create your own Big Bang environment t
 | 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 chart/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages |
+| sso.certificate_authority | string | `""` | Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see ./docs/example_configs/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 |

chart/values.yaml

@@ -56,7 +56,7 @@ sso:
     # -- Keycloak realm containing clients
     realm: baby-yoda
 
-  # -- Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see chart/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages
+  # -- Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see ./docs/example_configs/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages
   certificate_authority: ""
 
   # -- Keycloak realm's json web key output, obtained at https://<keycloak-server>/auth/realms/<realm>/protocol/openid-connect/certs

charter/BigBangPackages.md

@@ -2,7 +2,7 @@
 
 Each Big Bang Package is present in the [Big Bang Package](https://repo1.dso.mil/platform-one/big-bang/apps) repository and broken up into several sub-groupings.
 
-Each package has _at least_ two `CODEOWNERS`.  Responsibilities are outlined [here](ApplicationOwners.md).
+Each package has _at least_ two `CODEOWNERS`.  Responsibilities are outlined [here](PackageOwner.md).
 
 [[_TOC_]]
 

charter/Glossary.md

 # Glossary
 
-**Big Bang Application**: Is an application deployable onto Kubernetes using manifests inside the Big Bang Application Repository that meets all the requirements of [Application Requirements](ApplicationRequirements.md).
+**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.

charter/Teams.md

@@ -51,7 +51,7 @@ Execution in these two engineering efforts requires tight collaboration and feed
 #### Customers to Integration
 
 * Bugs
-* Environment specifics that can go back into Mock Environments as defined in [Testing](testing.md)
+* Environment specifics that can go back into Mock Environments as defined in [Testing](Testing.md)
 
 ### Product and Iron Bank
 

charter/Testing.md

@@ -17,7 +17,7 @@ A detailed description of the pipelines and how to execute the testing process o
 
 ## Application Testing
 
-When a Big Bang application developer submits changes to a particular Big Bang application, the application needs to be tested to ensure functionality, as well as compliance with core [Application Requirements](ApplicationRequirements.md).  
+When a Big Bang application developer submits changes to a particular Big Bang application, the application needs to be tested to ensure functionality, as well as compliance with core [Package Requirements](PackageRequirements.md).  
 
 A core feature of all testing capabilities is its ability to be run locally by developers using their own environment, or by other teams looking to test proposed changes to the application (e.g. IronBank as part of container creation).  The GitLab pipelines will be simple wrappers around these common testing and deployment tools.
 
@@ -86,7 +86,7 @@ Also note that the "helm.sh/hook-weight" can be used to order the creation and e
 
 ## Umbrella Testing
 
-The end consumable is the [Umbrella Application](Umbrella.md).  As new versions of Big Bang Applications become available, those changes need to be integrated into the Umbrella and tested.  Each Merge Request into the Umbrella Repo requires passing of an [Upgrade Tests](#upgrade-tests) and the [End to End Tests](#end-to-end-tests) for all mock environments.
+The end consumable is the [Umbrella Application](BigBang.md).  As new versions of Big Bang Applications become available, those changes need to be integrated into the Umbrella and tested.  Each Merge Request into the Umbrella Repo requires passing of an [Upgrade Tests](#upgrade-tests) and the [End to End Tests](#end-to-end-tests) for all mock environments.
 
 ### Environments
 

charter/packages/anchore/Architecture.md

@@ -135,7 +135,7 @@ _Note:_ within Big Bang, logs are captured by fluentbit and shipped to elastic b
 
 ### Monitoring
 
-Anchore Engine and Enterprise expose prometheus metrics in the API of each service if the config.yaml used by that service has the metrics.enabled key set to true. Each service exports its own metrics and is typically scraped by a Prometheus installation to gather the metrics. Anchore does not aggregate or distribute metrics between services. You should configure your Prometheus deployment or integration to check each Anchore service’s api (using the same port it exports), for the /metrics route. For more information, see [Anchore Enterprise Monitoring](https://docs.anchore.com/current/docs/monitoring/#monitoring-in-kubernetes-andor-helm-chart) and [metrics.md](./metrics.md).
+Anchore Engine and Enterprise expose prometheus metrics in the API of each service if the config.yaml used by that service has the metrics.enabled key set to true. Each service exports its own metrics and is typically scraped by a Prometheus installation to gather the metrics. Anchore does not aggregate or distribute metrics between services. You should configure your Prometheus deployment or integration to check each Anchore service’s api (using the same port it exports), for the /metrics route. For more information, see [Anchore Enterprise Monitoring](https://docs.anchore.com/current/docs/monitoring/#monitoring-in-kubernetes-andor-helm-chart).
 
 The Big Bang Anchore Helm chart has been modified to use your `monitoring:` values in Big Bang to automatically toggle metrics on/off.
 

charter/packages/kiali/Architecture.md

@@ -119,7 +119,7 @@ kiali:
 
 ## Single Sign on (SSO)
 
-SSO for Kiali is done via [built in OIDC](https://kiali.io/documentation/latest/configuration/authentication/openid/). Big Bang abstracts and simplifies the settings required for SSO setup. The following values can be used to configure SSO for Kiali:
+SSO for Kiali is done via [built in OIDC](https://kiali.io/docs/configuration/authentication/openid/). Big Bang abstracts and simplifies the settings required for SSO setup. The following values can be used to configure SSO for Kiali:
 
 ```yaml
 kiali:
@@ -134,16 +134,16 @@ sso:
     realm: baby-yoda
 ```
 
-If you require a more advanced SSO configuration there are additional ways to customize that are detailed in the [upstream OIDC docs](https://kiali.io/documentation/latest/configuration/authentication/openid/). This doc includes details on how to configure username, scope, timeout, proxies, and more. It also lists some [SSO provider specifics](https://kiali.io/documentation/latest/configuration/authentication/openid/#_provider_specific_instructions) which may be needed for configuring with different providers. If you want to provide any further configuration than what is included in the `kiali.sso` block, you can override the BB pre-configured SSO and pass values via `kiali.values.cr.spec.auth`.
+If you require a more advanced SSO configuration there are additional ways to customize that are detailed in the [upstream OIDC docs](https://kiali.io/docs/configuration/authentication/openid/). This doc includes details on how to configure username, scope, timeout, proxies, and more. It also lists some [SSO provider specifics](https://kiali.io/docs/configuration/authentication/openid/#_provider_specific_instructions) which may be needed for configuring with different providers. If you want to provide any further configuration than what is included in the `kiali.sso` block, you can override the BB pre-configured SSO and pass values via `kiali.values.cr.spec.auth`.
 
 ## Non-SSO Login
 
-If you do not configure Kiali with SSO you will have [4 options](https://kiali.io/documentation/latest/configuration/authentication/) for authentication. Big Bang will default to using the token method.
+If you do not configure Kiali with SSO you will have [4 options](https://kiali.io/docs/configuration/authentication/) for authentication. Big Bang will default to using the token method.
 
-- Token: Uses the Kubernetes service account token for authentication. This method makes use of your cluster's RBAC and you can create additional service accounts/tokens to restrict access. In general Kiali gives the same access as whatever is granted to the token used for login (additional [details provided upstream](https://kiali.io/documentation/latest/configuration/rbac/)).
+- Token: Uses the Kubernetes service account token for authentication. This method makes use of your cluster's RBAC and you can create additional service accounts/tokens to restrict access. In general Kiali gives the same access as whatever is granted to the token used for login (additional [details provided upstream](https://kiali.io/docs/configuration/rbac/)).
   - To get the default Kiali SA token for login: `kubectl get secret -n kiali | grep kiali-service-account-token | awk '{print $1}' | xargs kubectl get secret -n kiali -o go-template='{{.data.token | base64decode}}'`
-- OpenShift: This method will redirect users to the OpenShift console login page for authentication (and is only available for use on OpenShift). Details and setup can be seen in the [upstream docs](https://kiali.io/documentation/latest/configuration/authentication/openshift/).
-- Header: Requires use of reverse proxy to inject token into the header of the request. More details and considerations are noted [upstream](https://kiali.io/documentation/latest/configuration/authentication/header/).
+- OpenShift: This method will redirect users to the OpenShift console login page for authentication (and is only available for use on OpenShift). Details and setup can be seen in the [upstream docs](https://kiali.io/docs/configuration/authentication/openshift/).
+- Header: Requires use of reverse proxy to inject token into the header of the request. More details and considerations are noted [upstream](https://kiali.io/docs/configuration/authentication/header/).
 - Anonymous: No authentication, Kiali is open to whoever can access the URL.
 
 Example of how to override the authentication method:

charter/packages/twistlock/Architecture.md

@@ -4,10 +4,6 @@
 
 [Twistlock Administration Guide](https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/welcome/getting_started.html)
 
-## Contents
-
-[Developer Guide](docs/developer-guide.md)
-
 ## Big Bang Touch Points
 
 ```mermaid

docs/airgap/README.md

@@ -338,7 +338,7 @@ 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](./examples/values.yaml) file. Modify as needed and replace IP.
+All changes are modified in the custom [values.yaml](./scripts/values.yaml) file. Modify as needed and replace IP.
 
 Change the hostname for the installation. It is currently set to the development domain:
 

docs/configuration.md

@@ -38,7 +38,7 @@ In all four cases, Big Bang reads a single key named `values.yaml` that contains
 Before configuring Big Bang, it is expected that you have already setup:
 
 - A Kubernetes cluster
-- A [SOPS key pair](3_encryption.md)
+- A [SOPS key pair](encryption.md)
 - A Git repository to hold your configuration
   - Pull credentials for the Git repository (if not public)
 - An Iron Bank robot account for production, or a non-robot account for testing. Reference [Iron Bank authentication](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/docs/b_troubleshooting.md#iron-bank-authentication) for additional details.
@@ -51,7 +51,7 @@ At a minimum, the following items must be configured for a default Big Bang depl
 - [Big Bang version](#big-bang-version)
 - [Environment Git repository](#environment-location)
 - [Hostname](#hostname)
-- [SOPS private key reference](3_encryption.md).
+- [SOPS private key reference](encryption.md).
 - [Registry pull credentials](#registry-pull-credentials)
 
 The Big Bang [Environment Template](https://repo1.dso.mil/platform-one/big-bang/customers/template) has placeholders for all of the above.

docs/deployment.md

@@ -46,13 +46,13 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
 
 All changes to the Big Bang cluster should be made through Git.  After changes are pushed, Big Bang will automatically reconcile the difference with the cluster.
 
-> It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the [sync.sh](../hack/sync.sh) script.
+> It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the [sync.sh](../scripts/sync.sh) script.
 
 Changes to values can be tested in each environment using the named folders to override values and/or point to specific repo branches or tags.  After testing, the changes can be placed into the `./base` folder if the change is shared between all environments.
 
 ## Monitor
 
-The following commands will help you monitor the progress of the Big Bang deployment.  Review the [flowchart](./1_overview.md#Diagram), if needed, to understand the progression.  Use the [Troubleshooting Guide](./b_troubleshooting.md) if you have failures.
+The following commands will help you monitor the progress of the Big Bang deployment.  Review the [flowchart](./overview.md#Diagram), if needed, to understand the progression.  Use the [Troubleshooting Guide](./troubleshooting.md) if you have failures.
 
 1. Verify Flux is running
 

docs/developer/package-integration/package-integration-database.md

@@ -115,7 +115,7 @@ Example: [Mattermost](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob
 
 ## Validation
 
-For validating connection to the external database in your environment or testing in CI pipeline you will need to add the database specific values to your overrides file or `tests/ci/k3d/values.yaml` respectively.
+For validating connection to the external database in your environment or testing in CI pipeline you will need to add the database specific values to your overrides file or `./tests/test-values.yaml` respectively.
 
 Mattermost Example:
 

docs/developer/package-integration/package-integration-documentation.md

@@ -2,8 +2,8 @@
 
 Big Bang requires some additional documentation for supported packages to help user's understand how it interacts with other components.  The following are documents that should be created or updated for integration into Big Bang:
 
-- Package Architecture: See [Big Bang's Architecture instructions](../../charter/packages/ref-package/Architecture.md).  Examples are included in [charter/packages](../../charter/packages)
-- [Big Bang Packages](../../charter/BigBangPackages.md)
-- [Default Credentials](../guides/using_bigbang/default_credentials.md)
-- [Licensing](../understanding_bigbang/licensing_expectations.md)
-- [Minimum Hardware Requirements](../guides/prerequisites/minimum_hardware_requirements.md)
+- Package Architecture: See [Big Bang's Architecture instructions](../../../charter/packages/ref-package/Architecture.md).  Examples are included in [charter/packages](../../../charter/packages)
+- [Big Bang Packages](../../../charter/BigBangPackages.md)
+- [Default Credentials](../../guides/using_bigbang/default_credentials.md)
+- [Licensing](../../understanding_bigbang/licensing_expectations.md)
+- [Minimum Hardware Requirements](../../guides/prerequisites/minimum_hardware_requirements.md)

docs/developer/package-integration/package-integration-supported.md

@@ -84,11 +84,11 @@
        values: {}
    ```
 
-1. Edit tests/ci/k3d/values.yaml. These are the settings that the CI pipeline uses to run a deployment test.  Set your Package to be enabled and add any other necessary values. Where possible reduce the number of replicas to a minimum to reduce strain on the CI infrastructure. When you commit your code the pipeline will run. You can view the pipeline in the Repo1 Gitlab console. Fix any errors in the pipeline output. The pipeline automatically runs a "smoke" test. It deploys bigbang on a k3d cluster using the test values file.
+1. Edit `./tests/test-values.yaml`. These are the settings that the CI pipeline uses to run a deployment test.  Set your Package to be enabled and add any other necessary values. Where possible reduce the number of replicas to a minimum to reduce strain on the CI infrastructure. When you commit your code the pipeline will run. You can view the pipeline in the Repo1 Gitlab console. Fix any errors in the pipeline output. The pipeline automatically runs a "smoke" test. It deploys bigbang on a k3d cluster using the test values file.
 
 1. Add your packages name to the ORDERED_HELMRELEASES list in scripts/deploy/02_wait_for_helmreleases.sh.
 
-1. Create an overrrides directory as a sibling directory next to the bigbang code directory. Put your override yaml files in this directory. The reason we do this is to avoid modifying the bigbang values.yaml that is under source control. You could accidentally commit it with your secrets. Avoid that mistake and create a local overrides directory. One option is to copy the tests/ci/k3d/values.yaml to make the override-values.yaml and make modifications. The file structure is like this:
+1. Create an overrrides directory as a sibling directory next to the bigbang code directory. Put your override yaml files in this directory. The reason we do this is to avoid modifying the bigbang values.yaml that is under source control. You could accidentally commit it with your secrets. Avoid that mistake and create a local overrides directory. One option is to copy the `./tests/test-values.yaml` to make the override-values.yaml and make modifications. The file structure is like this:
     ```text
     ├── bigbang/
     └── overrides/
@@ -151,7 +151,7 @@ helm delete bigbang -n bigbang
 # Helm delete will not delete the bigbang namespace
 kubectl delete ns bigbang
 # Istio namespace will be stuck in "finalizing". So run the script to delete it.
-hack/remove-ns-finalizer.sh istio-system
+./script/remove-ns-finalizer.sh istio-system
 ```
 
 ### GitOps with Flux
@@ -171,15 +171,15 @@ watch kubectl get pod,helmrelease -A
 # Tear down
 kubectl delete -f dev/bigbang.yaml
 # Istio namespace will be stuck in "finalizing". So run the script to delete it. You will need 'jq' installed
-hack/remove-ns-finalizer.sh istio-system
+./scripts/remove-ns-finalizer.sh istio-system
 
 # If you have pushed code changes before the tear down, occasionally the bigbang deployments are not terminated because Flux has not had enough time to reconcile the helmreleases
 
 # Re-deploy bigbang
 kubectl apply -f dev/bigbang.yaml
 # Run the sync script.
-hack/sync.sh
+./scripts/sync.sh
 # Tear down
 kubectl delete -f dev/bigbang.yaml
-hack/remove-ns-finalizer.sh istio-system
+./scripts/remove-ns-finalizer.sh istio-system
 ```

docs/encryption.md

@@ -5,7 +5,6 @@ Table of Contents
 - [Big Bang Encryption](#big-bang-encryption)
   - [SOPS](#sops)
   - [Create Encryption Keys](#create-encryption-keys)
-    - [Samples](#samples)
   - [Configure SOPS](#configure-sops)
   - [Deploy Private Key](#deploy-private-key)
     - [GPG](#gpg)
@@ -39,23 +38,6 @@ To setup Big Bang with SOPS, a key pair must be created.  The private key is use
 
 > *GPG is not recommended for production use because the private key can be misplaced or compromised too easily
 
-### Samples
-
-If you plan to utilize Big Bang provided samples, either in the template or in this repository, setup the following:
-
-1. Install [gpg](https://gnupg.org/download/)
-1. Import the [Big Bang development key](../hack/bigbang-dev.asc)
-   > Do **NOT** use this key for any deployment.  It is only for demonstration purposes.
-
-   ```bash
-   gpg --import <private key>
-   ```
-
-1. Validate by decrypting and opening a sample file for editing
-
-   ```bash
-   sops <filename.enc.yaml>
-   ```
 
 ## Configure SOPS
 
@@ -88,7 +70,7 @@ SOPS uses `.sops.yaml` as a configuration file for which keys to use for newly c
 1. Deploy your SOPS private key to a secret named `sops-gpg` in the cluster
 
    ```bash
-   gpg --export-secret-keys --armor <new key fingerprint> | kubectl create secret generic sops-gpg -n bigbang --from-file=bigbangkey.asc=/dev/stdin
+   gpg --export-secret-keys --armor <new key fingerprint> | kubectl create secret generic sops-gpg -n bigbang --from-file=yourkey.asc=/dev/stdin
    ```
 
 ### AWS KMS

docs/example_configs/dev-sso-values.yaml

@@ -106,7 +106,7 @@ sso:
     -----END CERTIFICATE-----
 
   # # LetsEncrypt certificate authority for keycloak.bigbang.dev
-  # # Use this CA if you deployed Keycloak with *.bigbang.dev certificate using chart/keycloak-dev-values.yaml
+  # # Use this CA if you deployed Keycloak with *.bigbang.dev certificate using ./docs/example_configs/keycloak-dev-values.yaml
   # certificate_authority: |
   #   -----BEGIN CERTIFICATE-----
   #   MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw

docs/guides/deployment_scenarios/sso_quickstart.md

@@ -418,7 +418,7 @@ EOF
 
 helm upgrade --install bigbang \$HOME/bigbang/chart \
   --values https://repo1.dso.mil/platform-one/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
-  --values \$HOME/bigbang/chart/dev-k3d-values.yaml \
+  --values \$HOME/bigbang/docs/example_configs/opa-overrides-k3d.yaml \
   --values \$HOME/ib_creds.yaml \
   --values \$HOME/demo_values.yaml \
   --namespace=bigbang --create-namespace
@@ -485,7 +485,7 @@ twistlock:
 EOF
 
 helm upgrade --install bigbang \$HOME/bigbang/chart \
-  --values \$HOME/bigbang/chart/keycloak-dev-values.yaml \
+  --values \$HOME/bigbang/docs/example_configs/keycloak-dev-values.yaml \
   --values \$HOME/ib_creds.yaml \
   --values \$HOME/keycloak_qs_demo_values.yaml \
   --namespace=bigbang --create-namespace
@@ -699,7 +699,7 @@ EOF
 
 helm upgrade --install bigbang \$HOME/bigbang/chart \
   --values https://repo1.dso.mil/platform-one/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
-  --values \$HOME/bigbang/chart/dev-k3d-values.yaml \
+  --values \$HOME/bigbang/docs/example_configs/opa-overrides-k3d.yaml \
   --values \$HOME/ib_creds.yaml \
   --values \$HOME/demo_values.yaml \
   --values \$HOME/auth_service_demo_values.yaml \