diff --git a/website/source/guides/acl.html.markdown b/website/source/guides/acl.html.markdown index 480c3d34c..8e16b2131 100644 --- a/website/source/guides/acl.html.markdown +++ b/website/source/guides/acl.html.markdown @@ -22,7 +22,7 @@ The ACL system is designed to be easy to use and fast to enforce while providing * **ACL Tokens**. Requests to Nomad are authenticated by using bearer token. Each ACL token has a public Accessor ID which is used to name a token, and a Secret ID which is used to make requests to Nomad. The Secret ID is provided using a request header (`X-Nomad-Token`) and is used to authenticate the caller. Tokens are either `management` or `client` types. The `management` tokens are effectively "root" in the system, and can perform any operation. The `client` tokens are associated with one or more ACL policies which grant specific capabilities. - * **Capabilities**. Capabilties are the set of actions that can be performed. This includes listing jobs, submitting jobs, querying nodes, etc. A `management` token is granted all capabilities, while `client` tokens are granted specific capabilties via ACL Policies. The full set of capabilities is discussed below in the rule specifications. + * **Capabilities**. Capabilities are the set of actions that can be performed. This includes listing jobs, submitting jobs, querying nodes, etc. A `management` token is granted all capabilities, while `client` tokens are granted specific capabilities via ACL Policies. The full set of capabilities is discussed below in the rule specifications. ### ACL Policies @@ -72,7 +72,7 @@ Bootstrapping ACLs on a new cluster requires a few steps, outlined below: ### Enable ACLs on Nomad Servers -The APIs needed to manage policies and tokens are not enabled until ACLs are enabled. To begin, we need to enable the ACLs on the servers. If a multi-region setup is used, the authoritiative region should be enabled first. For each server: +The APIs needed to manage policies and tokens are not enabled until ACLs are enabled. To begin, we need to enable the ACLs on the servers. If a multi-region setup is used, the authoritative region should be enabled first. For each server: 1. Set `enabled = true` in the [`acl` stanza](/docs/agent/configuration/acl.html#enabled). 1. Set `authoritative_region` in the [`server` stanza](/docs/agent/configuration/server.html#authoritative_region). @@ -225,7 +225,7 @@ namespace "sensitive" { } ``` -Namespace rules are keyed by the namespace name they apply to. When no namespace is specified, the "default" namespace is the one used. For example, the above policy grants writeaccess to the default namespace, and read access to the sensitive namespace. In addition to the coarse grained `policy` specification, the `namespace` stanza allows setting a more fine grained list of `capabilities`. This includes: +Namespace rules are keyed by the namespace name they apply to. When no namespace is specified, the "default" namespace is the one used. For example, the above policy grants write access to the default namespace, and read access to the sensitive namespace. In addition to the coarse grained `policy` specification, the `namespace` stanza allows setting a more fine grained list of `capabilities`. This includes: * `deny` - When multiple policies are associated with a token, deny will take precedence and prevent any capabilities. * `list-jobs` - Allows listing the jobs and seeing coarse grain status. @@ -307,7 +307,7 @@ There's only one quota policy allowed per rule set, and its value is set to one # Advanced Topics -### Outages and Mulit-Region Replication +### Outages and Multi-Region Replication The ACL system takes some steps to ensure operation during outages. Clients nodes maintain a limited cache of ACL tokens and ACL policies that have recently or frequently been used, associated with a time-to-live (TTL). @@ -321,12 +321,12 @@ quorum is lost. The tokens and policies may become stale during this period as d replicating, but will be automatically fixed when the outage has been resolved. In a multi-region setup, there is a single authoritative region which is the source of truth for -ACL policies and global ACL tokens. All other regions asychronously replicate from the authoritative +ACL policies and global ACL tokens. All other regions asynchronously replicate from the authoritative region. When replication is interrupted, the existing data is used for request processing and may become stale. When the authoritative region is reachable, replication will resume and repair any inconsistency. -### Reseting ACL Bootstrap +### Resetting ACL Bootstrap If all management tokens are lost, it is possible to reset the ACL bootstrap so that it can be performed again. First, we need to determine the reset index, this can be done by calling the reset endpoint: diff --git a/website/source/guides/quotas.html.md b/website/source/guides/quotas.html.md index 7bcb3a548..f17e8d591 100644 --- a/website/source/guides/quotas.html.md +++ b/website/source/guides/quotas.html.md @@ -70,7 +70,7 @@ limit { A quota specification is composed of one or more resource limits. Each limit applies to a particular Nomad region. Within the limit object, operators can -specify the allowed cpu and memory usage. +specify the allowed CPU and memory usage. To create the particular quota, it is as simple as running: diff --git a/website/source/guides/securing-nomad.html.md b/website/source/guides/securing-nomad.html.md index f48af1431..95c1508f8 100644 --- a/website/source/guides/securing-nomad.html.md +++ b/website/source/guides/securing-nomad.html.md @@ -70,7 +70,7 @@ distributed to every node that requires access. ### Node Certificates -Once you have a CA certifacte and key you can generate and sign the +Once you have a CA certificate and key you can generate and sign the certificates Nomad will use directly. TLS certificates commonly use the fully-qualified domain name of the system being identified as the certificate's Common Name (CN). However, hosts (and therefore hostnames and IPs) are often @@ -217,16 +217,16 @@ tls { These two settings are important for ensuring all of Nomad's mTLS security properties are met. If [`verify_server_hostname`][verify_server_hostname] is -set to `false` the node's cerificate will be checked to ensure it is signed by +set to `false` the node's certificate will be checked to ensure it is signed by the same CA, but its role and region will not be verified. This means any service with a certificate signed by same CA as Nomad can act as a client or server of any region. [`verify_https_client`][verify_https_client] requires HTTP API clients to present a certificate signed by the same CA as Nomad's certificate. It may be -disabled to allow HTTP API clients (eg Nomad CLI, Consul, or curl) to +disabled to allow HTTP API clients (e.g. Nomad CLI, Consul, or curl) to communicate with the HTTPS API without presenting a client-side certificate. If -`verify_https_client` is enabled ony HTTP API clients presenting a certificate +`verify_https_client` is enabled only HTTP API clients presenting a certificate signed by the same CA as Nomad's certificate are allowed to access Nomad. ~> Enabling `verify_https_client` effectively protects Nomad from unauthorized diff --git a/website/source/guides/sentinel-policy.html.markdown b/website/source/guides/sentinel-policy.html.markdown index bd33d72d2..cd7f0858d 100644 --- a/website/source/guides/sentinel-policy.html.markdown +++ b/website/source/guides/sentinel-policy.html.markdown @@ -15,7 +15,7 @@ This is not present in the open source version of Nomad. # Sentinel Overview -Sentinel integrates with the ACL system, and provides the ability to do fine grained policy enforcment. Users must have appropriate permissions to perform an action, and then are subject to any applicable Sentinel policies: +Sentinel integrates with the ACL system, and provides the ability to do fine grained policy enforcement. Users must have appropriate permissions to perform an action, and then are subject to any applicable Sentinel policies: ![Sentinel Overview](/assets/images/sentinel.jpg) diff --git a/website/source/guides/sentinel/job.html.md b/website/source/guides/sentinel/job.html.md index e1e5b13f0..868e7d59e 100644 --- a/website/source/guides/sentinel/job.html.md +++ b/website/source/guides/sentinel/job.html.md @@ -11,7 +11,7 @@ description: |- The `job` object is made available to policies in the `submit-job` scope automatically, without an explicit import. The object maps to the [JSON Specification of jobs](/api/json-jobs.html), but fields differ slightly for better readability. -Sentinel convention for identifiers is lower case and separated by underscores. All fields on the job are accessed by the same name, converted to lower case and separating camal case to underscores. Here are some examples: +Sentinel convention for identifiers is lower case and separated by underscores. All fields on the job are accessed by the same name, converted to lower case and separating camel case to underscores. Here are some examples: | Job Field | Sentinel Accessor | | --------------------------------------- | ---------------------- |