website: address minor doc typos

website/source/docs/audit/syslog.html.md

@@ -12,7 +12,7 @@ Name: `syslog`
 
 The "syslog" audit backend writes audit logs to syslog.
 
-It currently does not support a configurable syslog desination, and
+It currently does not support a configurable syslog destination, and
 always sends to the local agent. This backend is only supported on Unix systems,
 and should not be enabled if any standby Vault instances do not support it.
 

website/source/docs/auth/token.html.md

@@ -231,7 +231,7 @@ of the cookie should be "token" and the value should be the token.
   <dd>
     Revokes a token but not its child tokens. When the token is revoked,
     all secrets generated with it are also revoked. All child tokens
-    are orpahaned, but can be revoked sub-sequently using `/auth/token/revoke/`.
+    are orphaned, but can be revoked sub-sequently using `/auth/token/revoke/`.
   </dd>
 
   <dt>Method</dt>

website/source/docs/auth/userpass.html.md

@@ -35,7 +35,7 @@ The endpoint for the login is `/login/USERNAME`.
 ## Configuration
 
 To use the "userpass" auth backend, an operator must configure it with
-userse that are allowed to authenticate. An example is shown below.
+users that are allowed to authenticate. An example is shown below.
 Use `vault help` for more details.
 
 ```

website/source/docs/concepts/dev-server.html.md

@@ -39,7 +39,7 @@ The properties of the dev server:
     via the API, you'll need to authenticate using the token printed out.
 
   * **Single unseal key** - The server is initialized with a single unseal
-    key. The Vault is already unsealed, but if you want to experiement with
+    key. The Vault is already unsealed, but if you want to experiment with
     seal/unseal, then only the single outputted key is required.
 
 ## Use Case

website/source/docs/concepts/ha.html.markdown

@@ -1,6 +1,6 @@
 ---
 layout: "docs"
-page_title: "High Availibility"
+page_title: "High Availability"
 sidebar_current: "docs-concepts-ha"
 description: |-
   Vault can be highly available, allowing you to run multiple Vaults to protect against outages.

website/source/docs/concepts/lease.html.md

@@ -70,6 +70,6 @@ where the secret was requested from. This lets you revoke trees of
 secrets. For example, to revoke all AWS access keys, you can do
 `vault revoke -prefix aws/`.
 
-This is very useful if there is an intrustion within a specific system:
+This is very useful if there is an intrusion within a specific system:
 all secrets of a specific backend or a certain configured backend can
 be revoked quickly and easily.

website/source/docs/concepts/policies.html.md

@@ -59,7 +59,7 @@ Only root or "sudo" privilege users are allowed to do this.
 
 ## Root Policy
 
-The "root" policy is special policy that can'be modified or removed.
+The "root" policy is a special policy that can be modified or removed.
 Any user associated with the "root" policy becomes a root user. A root
 user can do _anything_ within Vault.
 
@@ -79,7 +79,7 @@ with these commands for more information. They are very easy to use.
 To associate a policy with a user, you must consult the documentation for
 the authentication backend you're using.
 
-For tokens, they are assocated at creation time with `vault token-create`
+For tokens, they are associated at creation time with `vault token-create`
 and the `-policy` flags. Child tokens can be associated with a subset of
 a parent's policies. Root users can assign any policies.
 

website/source/docs/concepts/seal.html.md

@@ -67,6 +67,6 @@ There is also an API to seal the Vault. This will throw away the encryption
 key and require another unseal process to restore it. Sealing only requires
 a single operator with root privileges.
 
-This way, if there is a detected intrustion, the Vault data can be locked
+This way, if there is a detected intrusion, the Vault data can be locked
 quickly to try to minimize damages. It can't be accessed again without
 access to the master key shards.

website/source/docs/http/sys-raw.html.md

@@ -14,7 +14,7 @@ description: |-
   <dt>Description</dt>
   <dd>
       Reads the value of the key at the given path. This is the raw path in the
-        storage packend and not the logical path that is exposed via the mount system.
+        storage backend and not the logical path that is exposed via the mount system.
   </dd>
 
   <dt>Method</dt>
@@ -46,7 +46,7 @@ description: |-
   <dt>Description</dt>
   <dd>
       Update the value of the key at the given path. This is the raw path in the
-        storage packend and not the logical path that is exposed via the mount system.
+        storage backend and not the logical path that is exposed via the mount system.
   </dd>
 
   <dt>Method</dt>
@@ -77,7 +77,7 @@ description: |-
   <dt>Description</dt>
   <dd>
     Delete the key with given path. This is the raw path in the
-        storage packend and not the logical path that is exposed via the mount system.
+        storage backend and not the logical path that is exposed via the mount system.
   </dd>
 
   <dt>Method</dt>

website/source/docs/install/index.html.md

@@ -11,7 +11,7 @@ description: |-
 Installing Vault is simple. There are two approaches to installing Vault:
 downloading a precompiled binary for your system, or installing from source.
 
-Downloading a precombiled binary is easiest, and we provide downloads over
+Downloading a precompiled binary is easiest, and we provide downloads over
 TLS along with SHA256 sums to verify the binary is what we say it is.
 However, we use a 3rd party storage host, and some people feel that
 due to the importance of security with Vault, they'd rather compile it

website/source/docs/internals/architecture.html.md

@@ -47,7 +47,7 @@ clarify what is being discussed:
 
 * **Credential Backend** - A credential backend is used to authenticate users or applications which
   are connecting to Vault. Once authenticated, the backend returns the list of applicable policies
-  which shoud be applied. Vault takes an authenticated user and returns a client token that can
+  which should be applied. Vault takes an authenticated user and returns a client token that can
   be used for future requests. As an example, the `user-password` backend uses a username and password
   to authenticate the user. Alternatively, the `github` backend allows users to authenticate
   via GitHub.
@@ -78,7 +78,7 @@ A very high level overview of Vault looks like this:
 
 ![Architecture Overview](/assets/images/layers.png)
 
-Lets begin to break down this picture. There is a clear seperation of components
+Lets begin to break down this picture. There is a clear separation of components
 that are inside or outside of the security barrier. Only the storage backend and
 the HTTP API are outside, all other components are inside the barrier.
 
@@ -104,7 +104,7 @@ and enters the _unsealed_ state. Once unsealed, Vault loads all of the configure
 audit, credential and secret backends.
 
 The configuration of those backends must be stored in Vault since they are security
-sensitive. Only users with the correct permisisons should be able to modify them,
+sensitive. Only users with the correct permissions should be able to modify them,
 meaning they cannot be specified outside of the barrier. By storing them in Vault,
 any changes to them are protected by the ACL system and tracked by audit logs.
 
@@ -145,7 +145,7 @@ lease to expire, the expiration manager automatically revokes the secret.
 The core handles logging of requests and responses to the audit broker, which fans the
 request out to all the configured audit backends. Outside of the request flow, the core
 performs certain background activity. Lease management is critical, as it allows
-expired client tokens or secrets to be revoked automatically. Addiitonally, Vault handles
+expired client tokens or secrets to be revoked automatically. Additionally, Vault handles
 certain partial failure cases by using write ahead logging with a rollback manager.
 This is managed transparently within the core and is not user visible.
 

website/source/docs/internals/security.html.md

@@ -54,7 +54,7 @@ The following are not parts of the Vault threat model:
   reads would allow an attacker to snapshot in a well-known state and rollback state
   changes if that would be beneficial to them.
 
-* Protecting against the leakage of the existance of secret material. An attacker
+* Protecting against the leakage of the existence of secret material. An attacker
   that can read from the storage backend may observe that secret material exists
   and is stored, even if it is kept confidential.
 
@@ -111,7 +111,7 @@ policies are associated with a client), the highest access level permitted is us
 For example, if the "engineering" policy permits read/write access to the "eng/" path,
 and the "ops" policy permits read access to the "ops/" path, then the user gets the
 union of those. Policy is matched using a longest-prefix match, which is the most
-specific definied policy.
+specific defined policy.
 
 Certain operations are only permitted by "root" users, which is a distinguished
 policy built into Vault. This is similar to the concept of a root user on a Unix system

website/source/docs/internals/token.html.md

@@ -45,7 +45,7 @@ privileges. When a token is revoked, the entire sub-tree of tokens is revoked
 with it. This allows clients to safely generate child tokens and then revoke
 them all along with the root.
 
-Child tokens are very useful, espcially when combined with limited use tokens.
+Child tokens are very useful, especially when combined with limited use tokens.
 When a token is created their use count can be optionally specified. Providing
 a use count of one makes a _one time token_. This means the token can be used
 for a single request before being automatically revoked. This can be generalized

website/source/docs/secrets/consul/index.html.md

@@ -52,7 +52,7 @@ Success! Data written to: consul/roles/readonly
 
 The backend expects the policy to be base64 encoded, so we need to encode
 it properly before writing. The policy language is
-[documented by Consul](https://consul.io/docs/internals/acl.html), but we've definited a read-only policy.
+[documented by Consul](https://consul.io/docs/internals/acl.html), but we've defined a read-only policy.
 
 To generate a new set Consul ACL token, we simply read from that role:
 

website/source/docs/secrets/index.html.md

@@ -26,7 +26,7 @@ to the configured physical backend for Vault. A "read" turns into a
 "read" of the physical backend at the same path, a "write" turns into
 a write, etc. This is a lot like a normal filesystem.
 
-The "aws" backend, on the otherhand, behaves differently. When you
+The "aws" backend, on the other hand, behaves differently. When you
 write to `aws/config/root`, it expects a certain format and stores that
 information as configuration. You can't read from this path. When you
 read from `aws/<name>`, it looks up an IAM policy named `<name>` and

website/source/docs/secrets/postgresql/index.html.md

@@ -46,7 +46,7 @@ $ vault write postgresql/config/connection \
 ```
 
 In this case, we've configured Vault with the user "root" and password "vaulttest",
-connecting to a PostgreSQL instance in AWS RDS. The "postgres" databse name is being used.
+connecting to a PostgreSQL instance in AWS RDS. The "postgres" database name is being used.
 It is important that the Vault user have the `GRANT OPTION` privilege to manage users.
 
 Optionally, we can configure the lease settings for credentials generated
@@ -205,7 +205,7 @@ subpath for interactive help output.
         <span class="param">sql</span>
         <span class="param-flags">required</span>
         The SQL statements executed to create and configure the role.
-        Must be semi-colon seperated. The '{{name}}', '{{password}}' and
+        Must be semi-colon separated. The '{{name}}', '{{password}}' and
         '{{expiration}}' values will be substituted.
       </li>
     </ul>

website/source/docs/secrets/transit/index.html.md

@@ -1,6 +1,6 @@
 ---
 layout: "docs"
-page_title: "Secret Backend: Trasit"
+page_title: "Secret Backend: Transit"
 sidebar_current: "docs-secrets-transit"
 description: |-
   The transit secret backend for Vault encrypts/decrypts data in-transit. It doesn't store any secrets.
@@ -236,7 +236,7 @@ only encrypt or decrypt using the named keys they need access to.
 <dl class="api">
   <dt>Description</dt>
   <dd>
-    Dencrypts the provided ciphertext using the named key.
+    Decrypts the provided ciphertext using the named key.
   </dd>
 
   <dt>Method</dt>

website/source/intro/getting-started/deploy.html.md

@@ -103,7 +103,7 @@ Vault initialized with 5 keys and a key threshold of 3!
 
 Please securely distribute the above keys. Whenever a Vault server
 is started, it must be unsealed with 3 (the threshold)
- of thekeys above (any of the keys, as long as the total number equals
+of the keys above (any of the keys, as long as the total number equals
 the threshold).
 
 Vault does not store the original master key. If you lose the keys
@@ -153,7 +153,7 @@ Unseal Progress: 1
 
 After pasting in a valid key and confirming, you'll see that the Vault
 is still sealed, but progress is made. Vault knows it has 1 key out of 3.
-Due to the nature of the algorith, Vault doesn't know if it has the
+Due to the nature of the algorithm, Vault doesn't know if it has the
 _correct_ key until the threshold is reached.
 
 Also notice that the unseal process is stateful. You can go to another
@@ -162,7 +162,7 @@ that other computer can continue the unseal process.. This is incredibly
 important to the design of the unseal process: multiple people with multiple
 keys are required to unseal the Vault. The Vault can be unsealed from
 multiple computers and the keys should never be together. A single malicious
-operator does not have enough keys to be mailicious.
+operator does not have enough keys to be malicious.
 
 Continue with `vault unseal` to complete unsealing the Vault. Note that
 all 3 keys must be different, but they can be any other keys. As long as

website/source/intro/getting-started/help.html.md

@@ -75,7 +75,7 @@ help for an individual path. For this, just use `vault help` with a path
 that would match the regular expression for that path. Note that the path
 doesn't need to actually _work_. For example, we'll get the help below
 for accessing `aws/creds/operator`, even though we never created the `operator`
-rolek:
+role:
 
 ```
 $ vault help aws/creds/operator

website/source/intro/getting-started/secret-backends.html.md

@@ -100,7 +100,7 @@ storage backend (after encrypting data first).
 
 However, the "aws" backend (which you'll see soon), will read/write IAM
 policies and access tokens. So, while you might do a `vault read aws/deploy`,
-this isn't readnig from any _physical_ path "aws/deploy". Instead, the AWS
+this isn't reading from any _physical_ path "aws/deploy". Instead, the AWS
 backend is dynamically generating an access key based on the "deploy" policy.
 
 This abstraction is incredibly powerful. It lets Vault interface directly

website/source/intro/vs/consul.html.md

@@ -15,7 +15,7 @@ supports an ACL system to restrict access to keys and service information.
 While Consul can be used to store secret information and gate access using
 ACLs, it is not designed for that purpose. As such, data is not encrypted
 in transit nor at rest, it does not have pluggable authentication mechanisms,
-there is no per-request auditing mechansim.
+there is no per-request auditing mechanism.
 
 Vault is designed ground up a secret management solution. As such, it
 protects secrets in transit and at rest. It provides multiple authentication

website/source/intro/vs/hsm.html.md

@@ -17,7 +17,7 @@ cloud friendly. Amazon provides CloudHSM, but the minimum price point to
 even begin using CloudHSM is in the thousands of US dollars.
 
 Once an HSM is up and running, configuring it is generally very tedious,
-and the "API" to request secrets is also difficult ot use. Example: CloudHSM
+and the "API" to request secrets is also difficult to use. Example: CloudHSM
 requires SSH and setting up various keypairs manually. It is difficult to
 automate.
 
@@ -29,7 +29,7 @@ audit logs. In fact, you'd have multiple audit logs: requests to Vault
 as well as to the HSM.
 
 Vault can also do many things that HSMs cannot currently do, such
-as generating _dynamic secrets_. Insetad of storing AWS access keys directly
+as generating _dynamic secrets_. Instead of storing AWS access keys directly
 within Vault, Vault can generate access keys according to a specific
 policy on the fly. Vault has the potential of doing this for any
 system through its mountable secret backend system.