Fixing a few minor typos in markdown

docs/developer/aws-k3d-script.md

@@ -58,7 +58,7 @@ k3d-dev.sh -b -p -m -d -h
 The script uses the default AWS profile and defaults the VPC id and AMI id. 
 To change this default behavior you can export environment variables before running the script.  
 
-Run the script with a specifc AWS profile by first exporting the AWS_PROFILE environment variable
+Run the script with a specific AWS profile by first exporting the AWS_PROFILE environment variable
 ```shell
 export AWS_PROFILE=my-aws-profile
 ```

docs/developer/mdo-partybus-pipelines.md

@@ -5,4 +5,4 @@ At times Big Bang will have code for a plugin/binary/extension/etc that we'll ne
 1. Create a repo for the code within repo1 under https://repo1.dso.mil/platform-one/big-bang/apps/product-tools/
 1. This repo will need to be mirrored to code.il2.dso.mil. Create issue for the MDO team within [Jira IL2](https://jira.il2.dso.mil/servicedesk/customer/portal/73) as a "New Pipeline Request" and state that you would like a pipeline and repo created from this repo1 link.
 1. Create access token within repo1 project for the IL2 cloning, browse to Settings for the project > Access Tokens > check `read_repository` with a role of `Reporter` enter a name mentioning `partybus-il2` and ensure there is a date of expiration set for 1 year from this creation time > Click `Create project access token` and save the output at the top of the page to send to the MDO team over chat.il4 when prompted.
-1. Once mirroring to code.il2 is successful the pipeline will start running and depending on the languange, will run it's specific lint and unit testing stages and eventually get to trufflehog, fortify, dependencyCheck & sonarqube stages at the end. If any of these are throwing errors you will have to investigate why and can open issues to gain exceptions for any false-positives or other issues within [JIRA IL2](https://jira.il2.dso.mil/servicedesk/customer/portal/73) with a "Pipeline Exception Request".
+1. Once mirroring to code.il2 is successful the pipeline will start running and depending on the language, will run it's specific lint and unit testing stages and eventually get to trufflehog, fortify, dependencyCheck & sonarqube stages at the end. If any of these are throwing errors you will have to investigate why and can open issues to gain exceptions for any false-positives or other issues within [JIRA IL2](https://jira.il2.dso.mil/servicedesk/customer/portal/73) with a "Pipeline Exception Request".

docs/prerequisites/install-flux.md

@@ -28,7 +28,7 @@ kubectl apply -f https://repo1.dso.mil/platform-one/big-bang/bigbang/-/raw/maste
 
 > k apply -f flux.yaml, is equivalent to "flux install", but it installs a version of flux that's been tested and gone through IronBank.
 
-### Now You Can See New CRD Objects Types Inside of the Cluster
+### Now You Can See New CRD Objects Types Inside the Cluster
 
 ```shell
 kubectl get crds | grep flux
@@ -43,4 +43,4 @@ git clone https://repo1.dso.mil/platform-one/big-bang/bigbang.git
 ./bigbang/scripts/install_flux.sh
 ```
 
-> **NOTE** install_flux.sh requires arguments to run properly, calling it will print out a friendly USAGE mesage with required arguments needed to complete installation.
+> **NOTE** install_flux.sh requires arguments to run properly, calling it will print out a friendly USAGE message with required arguments needed to complete installation.

docs/prerequisites/kubernetes-preconfiguration.md

@@ -42,7 +42,7 @@ You can override bigbang's helm values so istio will provision a service of type
 ## Kubernetes Distribution Specific Notes
 
 * Note: P1 has forks of various [Kubernetes Distribution Vendor Repos](https://repo1.dso.mil/platform-one/distros), there's nothing special about the P1 forks.
-* We recommend you leverage the Vendors upstream docs in addition to any docs found in P1 Repos; infact, the Vendor's upstream docs are far more likely to be up to date.
+* We recommend you leverage the Vendors upstream docs in addition to any docs found in P1 Repos; in fact, the Vendor's upstream docs are far more likely to be up to date.
 
 ### Kubernetes Version
 

docs/understanding-bigbang/configuration/base-config.md

@@ -29,7 +29,7 @@ To start using Big Bang, you will need to create your own Big Bang environment t
 | 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 |
+| 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 registries:  - 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 |

docs/understanding-bigbang/package-architecture/argocd.md

@@ -4,7 +4,7 @@
 
 Argo CD is a declarative, [GitOps](https://www.gitops.tech/) continuous delivery tool for Kubernetes.
 
-ArgoCD is a kubernetes native tool that enables the delivery of GitOps practices.  It uses a git repository as a source of truth in defining the desired state.  It is implemented as a kubernetes controller continously montoring running applications and reconciling it against the desired state in the source git repository.
+ArgoCD is a kubernetes native tool that enables the delivery of GitOps practices.  It uses a git repository as a source of truth in defining the desired state.  It is implemented as a kubernetes controller continuously monitoring running applications and reconciling it against the desired state in the source git repository.
 
 
 Argo CD uses an Application Controller component to continuously watch applications that are executing.  Argo CD then differentiates the applications live state against the target state that resides in the Git repository. It supports a range of configuration management tools such as [Helm](https://helm.sh/), [kustomize](https://kustomize.io/), [ksonnet](https://ksonnet.io/get-started/), and [jsonnet](https://jsonnet.org/).

docs/understanding-bigbang/package-architecture/cluster-auditor.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Cluster Auditor(CA) pulls contstraints from the kubernetes API, transforms them and inserts them into Prometheus to be displayed in a Grafana Dashboard. Cluster Auditor uses OPA Gatekeeper CRDs and native kubernetes [objects](https://repo1.dso.mil/platform-one/big-bang/apps/core/cluster-auditor/-/blob/main/chart/templates/clusterRole.yaml).
+Cluster Auditor(CA) pulls constraints from the kubernetes API, transforms them and inserts them into Prometheus to be displayed in a Grafana Dashboard. Cluster Auditor uses OPA Gatekeeper CRDs and native kubernetes [objects](https://repo1.dso.mil/platform-one/big-bang/apps/core/cluster-auditor/-/blob/main/chart/templates/clusterRole.yaml).
 
 ## Big Bang Touch Points