update docs to mention the need for logging into Harbor before running umbrella

.gitignore

@@ -20,3 +20,14 @@ npm-debug.log*
 # (used frequently in deployments)
 patch.yaml
 notes
+
+# Visual Studio Code
+.vscode/*
+!.vscode/settings.json
+!.vscode/tasks.json
+!.vscode/launch.json
+!.vscode/extensions.json
+*.code-workspace
+
+# Local History for Visual Studio Code
+.history/
\ No newline at end of file

docs/1_overview.md

@@ -75,11 +75,11 @@ In addition, the following packages can be added onto the default deployment:
 
 ## Architecture
 
-The diagram below shows a typcial deployment of Big Bang into a Kubernetes cluster.  The items in blue require user interaction.  The remaining items are automated by Big Bang.
+The diagram below shows a typical deployment of Big Bang into a Kubernetes cluster.  The items in blue require user interaction.  The remaining items are automated by Big Bang.
 
 ### Configuration
 
-1. The user must [setup an encryption key pair](./3_encryption.md) for SOPS and store the private key securely (e.g. KMS).  This shoud **NOT** be stored in Git.
+1. The user must [setup an encryption key pair](./3_encryption.md) for SOPS and store the private key securely (e.g. KMS).  This should **NOT** be stored in Git.
 1. The user should then [configure Big Bang](./4_configuration.md) values and secrets for the targeted Kubernetes cluster.
 1. All secrets should be encrypted with SOPS to protect them.
 1. Once all of the configuration has been completed, it must be pushed to a Git repository.
@@ -97,7 +97,7 @@ The diagram below shows a typcial deployment of Big Bang into a Kubernetes clust
    1. The repository is reconciled first, pulling the Helm chart from Git.
    1. The Helm Release will check for the Helm chart and the Secrets / ConfigMaps deployed before performing a Helm install
 1. Once the Helm release deploys the Helm chart for Big Bang, each package that is enabled will have a Flux Git Repository and Helm Release resource deployed.
-1. All of the package Git repos containing Helm charts will be pulled so that Flux can reconcile dependencies.
+1. All of the package Git repositories containing Helm charts will be pulled so that Flux can reconcile dependencies.
 1. Each package's Helm Release has dependencies built in.  Flux will reconcile these dependencies and deploy the Helm chart for the package once all of the dependencies are ready.
 1. Once all of the packages are ready, Big Bang will monitor Git periodically for changes and reconcile using the methods above.
 

docs/2_getting_started.md

@@ -37,7 +37,7 @@ Table of Contents
     # The script will do the following:
     #   Check flux prerequisites
     #   Interactively login to Iron Bank and store credentials in Secret
-    #   Install flux into Kubernetes cluser using Iron Bank repo
+    #   Install flux into Kubernetes cluster using Iron Bank repo
     #   Remove Iron Bank credentials from cluster
     hack/flux-install.sh
     ```

docs/3_encryption.md

@@ -12,10 +12,10 @@ Table of Contents
     - [AWS KMS](#aws-kms)
     - [GCP KMS](#gcp-kms)
     - [Azure KeyVault](#azure-keyvault)
-    - [Hashicorp Vault](#hashicorp-vault)
+    - [HashiCorp Vault](#hashicorp-vault)
   - [Configure Big Bang](#configure-big-bang)
 
-Big Bang follows a [GitOps](https://www.weave.works/technologies/gitops/) approach to managing the Big Bang Kubernetes cluster configuration.  Using GitOps, we must securely store secrets in Git using encryption.  The private key, which is stored in key storage, is used by the continous deployment tool to decrypt and deploy the secrets for use in the cluster.
+Big Bang follows a [GitOps](https://www.weave.works/technologies/gitops/) approach to managing the Big Bang Kubernetes cluster configuration.  Using GitOps, we must securely store secrets in Git using encryption.  The private key, which is stored in key storage, is used by the continuous deployment tool to decrypt and deploy the secrets for use in the cluster.
 
 ## SOPS
 
@@ -33,9 +33,9 @@ To setup Big Bang with SOPS, a key pair must be created.  The private key is use
 | [GNU Privacy Guard (GPG)*](https://gnupg.org/) | `gpg --full-generate-key` | Use `key type` = `RSA and RSA`, `keysize` = `4096`, `expiration` = `0` |
 | [Amazon Web Services (AWS) Key Management Service (KMS)](https://aws.amazon.com/kms/) | [Link](https://github.com/mozilla/sops#2usage) | [Advanced setup help](https://github.com/mozilla/sops#26kms-aws-profiles) (e.g. roles, profiles, contexts)
 | [Google Cloud Platform (GCP) Key Management Service (KMS)](https://cloud.google.com/security-key-management) | [Link](https://github.com/mozilla/sops#encrypting-using-gcp-kms) |
-| [Hashicorp Vault](https://www.vaultproject.io/) | [Link](https://github.com/mozilla/sops#23encrypting-using-azure-key-vault) |
+| [HashiCorp Vault](https://www.vaultproject.io/) | [Link](https://github.com/mozilla/sops#23encrypting-using-azure-key-vault) |
 
-> *GPG is not recommended for production use because the private key can be misplaced or comprimised too easily
+> *GPG is not recommended for production use because the private key can be misplaced or compromised too easily
 
 ### Samples
 
@@ -59,18 +59,18 @@ If you plan to utilize Big Bang provided samples, either in the template or in t
 
 SOPS uses `.sops.yaml` as a configuration file for which keys to use for newly created files.  Once a file is created, the key fingerprints are stored in the file and must be re-keyed to use any changes to `.sops.yaml`.
 
-1. Follow the [SOPS instructions](https://github.com/mozilla/sops#210using-sopsyaml-conf-to-select-kmspgp-for-new-files) to configure `.sops.yaml` based on the encryption method you used.  Multiple keys of the same type can be added using the block scalar yaml construct, `>-`, and separating them by a comman and newline.
+1. Follow the [SOPS instructions](https://github.com/mozilla/sops#210using-sopsyaml-conf-to-select-kmspgp-for-new-files) to configure `.sops.yaml` based on the encryption method you used.  Multiple keys of the same type can be added using the block scalar yaml construct, `>-`, and separating them by a comma and newline.
    > If you are using the Big Bang sample files, make sure to remove the development Big Bang key.
 
-1. Add the following regex to only encrypt data in the yaml files
+2. Add the following regex to only encrypt data in the yaml files
 
     ```yaml
     creation_rules:
     - encrypted_regex: '^(data|stringData)$'
     ```
 
-1. Save `.sops.yaml` in the root of folder of your configuration
-1. If you have existing secrets, use the following to re-key them with the configuration in `.sops.yaml`
+3. Save `.sops.yaml` in the root of folder of your configuration
+4. If you have existing secrets, use the following to re-key them with the configuration in `.sops.yaml`
 
    ```bash
    # You must have the old private key to rekey the file
@@ -101,7 +101,7 @@ TBD - [This article](https://blog.doit-intl.com/injecting-secrets-from-aws-gcp-o
 
 TBD - [This article](https://blog.doit-intl.com/injecting-secrets-from-aws-gcp-or-vault-into-a-kubernetes-pod-d5a0e84ba892) may help to automate secret consumption in Kubernetes.
 
-### Hashicorp Vault
+### HashiCorp Vault
 
 TBD - [This article](https://blog.doit-intl.com/injecting-secrets-from-aws-gcp-or-vault-into-a-kubernetes-pod-d5a0e84ba892) may help to automate secret consumption in Kubernetes.
 

docs/4_configuration.md

@@ -41,7 +41,7 @@ Before configuring Big Bang, it is expected that you have already setup:
 - A [SOPS key pair](3_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)
+- 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.
 - Certificates specific to your environment (if needed)
 
 ## Minimum Viable Configuration
@@ -80,7 +80,7 @@ Registry credentials are used to pull images for Big Bang.  By default, it point
 
 ### `flux`
 
-Flux settings are used to setup the default continous deployment configuration for Big Bang packages.
+Flux settings are used to setup the default continuos deployment configuration for Big Bang packages.
 
 | Key | Description | Type | Default |
 |--|--|--|--|

docs/5_deployment.md

@@ -14,7 +14,7 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
 
 ## Installation
 
-1. Before pushing changes to Git, validate all configuration is syntatically correct.
+1. Before pushing changes to Git, validate all configuration is syntactically correct.
 
    ```bash
    # If everything is successful, YAML should be output
@@ -27,7 +27,7 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
    git push
    ```
 
-1. Validate the Kuberbernetes context is correct
+1. Validate the Kubernetes context is correct
 
    ```bash
    # This should match the environment you intend to deploy

docs/b_troubleshooting.md

@@ -17,7 +17,7 @@ Big Bang is configured to retry failed package installations and upgrades.  Befo
 
 | Symptom | Cause | Resolution |
 |--|--|--|
-| Despite entering correct credentials, get `anauthorized: authentication required` from Iron Bank | Using a non-robot account with an expired token | Login with the non-robot account manually at `registry1.dso.mil`, then retry.  For production, contact the Iron Bank team to obtain a robot account and update pull credentials to use it in your environment |
+| Despite entering correct credentials, get `unauthorized: authentication required` from Iron Bank | Using a non-robot account with an expired token | Login with the non-robot account manually at `registry1.dso.mil`, then retry.  For production, contact the Iron Bank team to obtain a robot account and update pull credentials to use it in your environment |
 
 ## Flux install
 
@@ -75,7 +75,7 @@ kubectl get events --field-selector involvedObject.kind=HelmRelease -A
 
 | Symptom | Cause | Resolution |
 |--|--|--|
-| `Reconcilliation in Progress` | This is normal and indicates flux is currently applying updates | Wait |
+| `Reconciliation in Progress` | This is normal and indicates flux is currently applying updates | Wait |
 | `dependency ... is not ready` | This is normal and indicates flux is currently waiting on another resource to complete | Wait |
 | `Error: YAML parse error on ...` | Syntax error in helm chart | Use `helm template` to narrow down the problem.  Fix it and commit to Git |
 | `Helm install failed: failed to create resource ... unable to create new content in namespace because it is being terminated` | This seems to happen when a re-deploy of Big Bang occurs to early after a Big Bang delete. |  Try to remove the namespace using `kubectl get ns <stuck namespace> -o json | jq '.spec.finalizers = []' | kubectl replace --raw "/api/v1/namespaces/$NS/finalize" -f`.  If this does not work, a cluster restart may be necessary. |
@@ -102,7 +102,7 @@ kubectl get events --field-selector involvedObject.kind=Kustomization -A
 | `evalsymlink failure ... no such file or directory` | A reference to a file in `kustomization.yaml` is incorrect | Use `kustomize build` on the `<env>` folder or `base` folder to narrow down the problem.  Fix the error and push to Git. |
 | `Error: accumulating resources ...` | A reference to a base is incorrect | Use `kustomize build` on the `<env>` folder or `base` folder to narrow down the problem.Review the `bases:` section for correct paths to find the error.  Fix the error and push to Git. |
 | `Error fetchingref: fatal: couldn't find remote ref ...` | The branch, tag, or sha used for a remote base is incorrect | Use `kustomize build` on the `<env>` folder or `base` folder to narrow down the problem.  It is likely the remote reference to the Big Bang's Kustomize in the `base` folder.  Review the `bases:` section for correct paths to find the error.  Fix the error and push to Git. |
-| `Error: merging from generator ...` | Kustomize is trying to merge with a resource that is non-existant.  This is usually due to naming the merging `ConfigMap` or `Secret` incorrectly compared to a base `ConfigMap` or `Secret`. | Use `kustomize build` on the `<env>` folder or `base` folder to narrow down the problem.  Look for the keyword `merge` in the `kustomization.yaml` files and verify the `name` is correctly set. |
+| `Error: merging from generator ...` | Kustomize is trying to merge with a resource that is non-existent.  This is usually due to naming the merging `ConfigMap` or `Secret` incorrectly compared to a base `ConfigMap` or `Secret`. | Use `kustomize build` on the `<env>` folder or `base` folder to narrow down the problem.  Look for the keyword `merge` in the `kustomization.yaml` files and verify the `name` is correctly set. |
 
 ## Packages
 

docs/c_development.md

@@ -4,7 +4,7 @@
 
 Included here is a setup that will allow you to checkout and begin development using your workstation and a minimal EC2 instance in AWS.
 
-### Prequisites
+### Prerequisites
 
 #### Access
 + [AWS GovCloud (US) EC2](https://console.amazonaws-us-gov.com/ec2)
@@ -165,7 +165,7 @@ ssh -i $AWSUSERNAME.pem ubuntu@$YOURPUBLICEC2IP
 # Remove any old Docker items
 sudo apt remove docker docker-engine docker.io containerd runc
 
-# Install all pre-reqs for Docker
+# Install all prerequisites for Docker
 sudo apt update
 sudo apt install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common
 
@@ -236,9 +236,9 @@ optional:
 `--api-port 0.0.0.0:38787` Chooses a port for the API server instead of being assigned a random one. You can set this to any port number that you want.
 `-v /etc/machine-id:/etc/machine-id` volume mount so k3d nodes have a file at /etc/machine-id for fluentbit DaemonSet.
 
-- Once your cluster is up, you can copy the kubeconfig from the EC2 instance to your workstation and update the IP Address. If you do not have an existing configuration to preserve on your local workstation, you can delete and recreate the configuration file.
+- Once your cluster is up, you can copy the ./kube/config file from the EC2 instance to your workstation and update the IP Address. If you do not have an existing configuration to preserve on your local workstation, you can delete and recreate the configuration file.
 
-Copy the contents of the remote configuation file.
+Copy the contents of the remote configuration file.
 
 ```bash
 cat ~/.kube/config
@@ -249,7 +249,7 @@ cat ~/.kube/config
 Update the configuration file on your local workstation.
 
 ```bash
-# Remove existing configuation if defined.
+# Remove existing configuration if defined.
 rm ~/.kube/config
 
 # Create empty configuation
@@ -259,7 +259,7 @@ touch ~/.kube/config
 # (Prevents Helm warnings)
 chmod go-r ~/.kube/config
 
-# Open vi to edit configuation
+# Open vi to edit configuration
 vi ~/.kube/config
 ```
 
@@ -379,7 +379,7 @@ helm upgrade -i bigbang chart -n bigbang --create-namespace --set registryCreden
 <X.X.X.X>     kibana.bigbang.dev
 <X.X.X.X>     kiali.bigbang.dev
 <X.X.X.X>     prometheus.bigbang.dev
-<X.X.X.X>     graphana.bigbang.dev
+<X.X.X.X>     grafana.bigbang.dev
 ```
 
 - You can watch your install take place with
@@ -392,7 +392,7 @@ helm upgrade -i bigbang chart -n bigbang --create-namespace --set registryCreden
 watch kubectl get po,gitrepository,kustomizations,helmreleases -A
 ```
 
-As of this time, Twistlock is the last thing to be installed. Once you see Twistlock sync and everything else is up and healty you are fully installed.
+As of this time, Twistlock is the last thing to be installed. Once you see Twistlock sync and everything else is up and healthy you are fully installed.
 
 ### Addendum for Amazon Linux 2