Fix changelog typos (#2636)

CHANGELOG.md

@@ -14,21 +14,21 @@ Canonical reference for changes, improvements, and bugfixes for Boundary.
     * `{{ .User.Id }}`: the user's ID
     * `{{ .User.Name }}`: the user's name (from the user resource)
     * `{{ .User.FullName }}`: the user's name (from the account corresponding to
-    theprimary auth method in the user's scope; this may not be populated or
+    the primary auth method in the user's scope; this may not be populated or
     maybe different than the account name in the template)
     * `{{ .User.Email }}`: the user's email address (same caveat as `FullName`)
     * `{{ .Account.Id }}`: the account's ID
     * `{{ .Account.Name }}`: the account's name (from the account resource)
     * `{{ .Account.LoginName }}`: the account's login name (if used by that type
-    of ccount)
+    of account)
     * `{{ .Account.Subject }}`: the account's subject (if used by that type
-    of ccount)
+    of account)
     * `{{ .Account.Email }}`: the account's email (if used by that type
     of account)
 
     Additionally, there is currently a single function that strips the rest of a
     string after a specified substring; this is useful for pulling an user/account name from an email address. In the following example it uses the account email can be any other parameter:
-    
+
     * `{{ truncateFrom .Account.Email "@" }}`: this would turn `foo@example.com` into `foo`
 
 ### Bug Fixes
@@ -55,7 +55,7 @@ Canonical reference for changes, improvements, and bugfixes for Boundary.
 * In order to standardize on the templating format, [templates in
   grants](https://developer.hashicorp.com/boundary/docs/concepts/security/permissions/permission-grant-formats#templates)
   now are documented to use the new capitalization and format; however, the
-  previous style will continue to work. 
+  previous style will continue to work.
 
 ## 0.11.0 (2022/09/27)
 
@@ -86,8 +86,8 @@ Canonical reference for changes, improvements, and bugfixes for Boundary.
 ### New and Improved
 
 * vault: (HCP Boundary only): Private Vault clusters can be used with HCP Boundary by using PKI workers
-  deployed in the same network as a private cluster. Tags are used to control which PKI workers can manage private Vault 
-  requests by specifying a `worker_filter` attribute when configuring a Vault credential store. 
+  deployed in the same network as a private cluster. Tags are used to control which PKI workers can manage private Vault
+  requests by specifying a `worker_filter` attribute when configuring a Vault credential store.
 * credentials: There is now a `json` credential type supported by `static`
   credential stores that allows submitting a generic JSON object to Boundary for
   use with credential brokering workflows
@@ -608,7 +608,7 @@ isolate transactions and prevent resource contention that caused deadlocks.
 
 ### Deprecations/Changes
 
-* permissions: Fix bug in _Host Sets_ service that authenticated requests  
+* permissions: Fix bug in _Host Sets_ service that authenticated requests
   againist incorrect grant actions. This bug affects the _SetHosts_, _AddHosts_
   and _RemoveHosts_ paths that do not have wildcard (`*`) action grants.
   If affected, please update grant actions as follows:
@@ -734,7 +734,7 @@ isolate transactions and prevent resource contention that caused deadlocks.
   `audit`. All events are emitted as
   [cloudevents](https://github.com/cloudevents/spec/blob/v1.0.1/spec.md) and we
   support both a `cloudevents-json` format and custom Boundary
-  `cloudevents-text` format.   
+  `cloudevents-text` format.
 
   **Notes**:
   * There are still a few lingering hclog bits within Boundary. If you wish to
@@ -749,12 +749,12 @@ isolate transactions and prevent resource contention that caused deadlocks.
   * Observation events are MVP and contain a minimal set of observations about a
     request. Observations are aggregated for each request, so only one
     observation event will be emitted per request. We anticipate that a rich set
-    of aggregate data about each request will be developed over time.   
+    of aggregate data about each request will be developed over time.
   * Audit events are a WIP and will only be emitted if they are both enabled
     and the env var `BOUNDARY_DEVELOPER_ENABLE_EVENTS` equals true.  We
     anticipate many changes for audit events before they are generally available
     including what data is included and different options for
-    redacting/encrypting that data.   
+    redacting/encrypting that data.
 
 
   PRs: