Updates documentation.

website/source/api/acl.html.md

@@ -10,6 +10,54 @@ description: |-
 
 The `/acl` endpoints create, update, destroy, and query ACL tokens in Consul. For more information about ACLs, please see the [ACL Guide](/docs/guides/acl.html).
 
+## Bootstrap ACLs
+
+This endpoint does a special one-time bootstrap of the ACL system, making the first
+management token if the [`acl_master_token`](/docs/agent/options.html#acl_master_token)
+is not specified in the Consul server configuration, and if the cluster has not been
+bootstrapped previously. This is available in Consul 0.9.1 and later, and requires all
+Consul servers to be upgraded in order to operate.
+
+This provides a mechanism to bootstrap ACLs without having any secrets present in Consul's
+configuration files.
+
+| Method | Path                         | Produces                   |
+| ------ | ---------------------------- | -------------------------- |
+| `PUT`  | `/acl/bootstrap`             | `application/json`         |
+
+The table below shows this endpoint's support for
+[blocking queries](/api/index.html#blocking-queries),
+[consistency modes](/api/index.html#consistency-modes), and
+[required ACLs](/api/index.html#acls).
+
+| Blocking Queries | Consistency Modes | ACL Required |
+| ---------------- | ----------------- | ------------ |
+| `NO`             | `none`            | `none`       |
+
+### Sample Request
+
+```text
+$ curl \
+    --request PUT \
+    https://consul.rocks/v1/acl/bootstrap
+```
+
+### Sample Response
+
+```json
+{
+  "ID": "adf4238a-882b-9ddc-4a9d-5b6758e4159e"
+}
+```
+
+You can detect if something has interfered with the ACL bootstrapping process by
+checking the response code. A 200 response means that the bootstrap was a success, and
+a 403 means that the cluster has already been bootstrapped, at which point you should
+consider the cluster in a potentially compromised state.
+
+The returned token will be a management token which can be used to further configure the
+ACL system. Please see the [ACL Guide](/docs/guides/acl.html) for more details.
+
 ## Create ACL Token
 
 This endpoint makes a new ACL token.

website/source/docs/guides/acl.html.md

@@ -190,7 +190,7 @@ The first step for bootstrapping ACLs is to enable ACLs on the Consul servers in
 datacenter. In this example, we are configuring the following:
 
 1. An ACL datacenter of "dc1", which is where these servers are
-2. An ACL master token of "b1gs33cr3t"
+2. An ACL master token of "b1gs33cr3t"; see below for an alternative using the [/v1/acl/bootstrap API](/api/acl.html#bootstrap-acls)
 3. A default policy of "deny" which means we are in whitelist mode
 4. A down policy of "extend-cache" which means that we will ignore token TTLs during an
    outage
@@ -218,6 +218,22 @@ a server acquires cluster leadership. If you would like to install or change the
 [`acl_master_token`](/docs/agent/options.html#acl_master_token) in the configuration
 for all servers. Once this is done, restart the current leader to force a leader election.
 
+In Consul 0.9.1 and later, you can use the [/v1/acl/bootstrap API](/api/acl.html#bootstrap-acls)
+to make the initial master token, so a token never needs to be placed into a configuration
+file. To use this approach, omit `acl_master_token` from the above config and then call the API:
+
+```text
+$ curl \
+    --request PUT \
+    http://127.0.0.1:8500/v1/acl/bootstrap
+
+{"ID":"fe3b8d40-0ee0-8783-6cc2-ab1aa9bb16c1"}
+```
+
+The returned token is the initial management token, which is randomly generated by Consul.
+It's only possible to bootstrap one time, and bootstrapping will be disabled if a master
+token was configured and created.
+
 Once the ACL system is bootstrapped, ACL tokens can be managed through the
 [ACL API](/api/acl.html).
 
@@ -237,7 +253,7 @@ own internal operations like updating its node information in the catalog and pe
 [anti-entropy](/docs/internals/anti-entropy.html) syncing. We can create a token using the
 ACL API, and the ACL master token we set in the previous step:
 
-```
+```text
 $ curl \
     --request PUT \
     --header "X-Consul-Token: b1gs33cr3t" \
@@ -267,7 +283,7 @@ configuration and restart the servers once more to apply it:
 In Consul 0.9.1 and later you can also introduce the agent token using an API,
 so it doesn't need to be set in the configuration file:
 
-```
+```text
 $ curl \
     --request PUT \
     --header "X-Consul-Token: b1gs33cr3t" \
@@ -302,7 +318,7 @@ with a configuration file that enables ACLs:
 Similar to the previous example, in Consul 0.9.1 and later you can also introduce the
 agent token using an API, so it doesn't need to be set in the configuration file:
 
-```
+```text
 $ curl \
     --request PUT \
     --header "X-Consul-Token: b1gs33cr3t" \
@@ -354,7 +370,7 @@ configure Consul's behavior when no token is supplied. The anonymous token is ma
 like any other ACL token, except that `anonymous` is used for the ID. In this example
 we will give the anonymous token read privileges for all nodes:
 
-```
+```text
 $ curl \
     --request PUT \
     --header "X-Consul-Token: b1gs33cr3t" \
@@ -407,7 +423,7 @@ consul.                 0       IN      SOA     ns.consul. postmaster.consul. 14
 Now we get an `NXDOMAIN` error because the anonymous token doesn't have access to the
 "consul" service. Let's add that to the anonymous token's policy:
 
-```
+```text
 $ curl \
     --request PUT \
     --header "X-Consul-Token: b1gs33cr3t" \