From 95ef6552deec235a8eec30c5d3d0829addcd1547 Mon Sep 17 00:00:00 2001 From: James Turnbull Date: Wed, 14 Dec 2016 11:11:14 -0500 Subject: [PATCH] Edits to the authorization/acl guide --- website/source/intro/getting-started/acl.html.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/website/source/intro/getting-started/acl.html.md b/website/source/intro/getting-started/acl.html.md index d72774adc8..359b024871 100644 --- a/website/source/intro/getting-started/acl.html.md +++ b/website/source/intro/getting-started/acl.html.md @@ -12,13 +12,13 @@ Access control policies in Vault control what a user can access. In the last section, we learned about _authentication_. This section is about _authorization_. -Whereas for authentication Vault has multiple options or backends that -can be enabled and used, the authorization or policies of Vault are always -the same format. All authentication backends must map identities back to +For authentication Vault has multiple options or backends that +can be enabled and used. For authorization and access control policies Vault always +uses the same format. All authentication backends must map identities back to the core policies that are configured with Vault. When initializing Vault, there is always one special policy created -that can't be removed: the "root" policy. This policy is a special policy +that can't be removed: the `root` policy. This policy is a special policy that gives superuser access to everything in Vault. An identity mapped to the root policy can do anything. @@ -54,7 +54,7 @@ to `secret/foo`, where only read access is allowed. Policies default to deny, so any access to an unspecified path is not allowed. The policy language changed slightly in Vault 0.2, [see this page for details](/docs/concepts/policies.html). -Save the above policy as `acl.hcl`. +Save the above policy in a file called `acl.hcl`. ## Writing the Policy @@ -116,7 +116,7 @@ Vault is the single policy authority, unlike auth where you can mount multiple backends. Any mounted auth backend must map identities to these core policies. -Use the `vault path-help` system with your auth backend to determine how the +We use the `vault path-help` system with your auth backend to determine how the mapping is done, since it is specific to each backend. For example, with GitHub, it is done by team using the `map/teams/` path: @@ -125,7 +125,7 @@ $ vault write auth/github/map/teams/default value=secret Success! Data written to: auth/github/map/teams/default ``` -For GitHub, the "default" team is the default policy set that everyone +For GitHub, the `default` team is the default policy set that everyone is assigned to no matter what team they're on. Other auth backends use alternate, but likely similar mechanisms for