kemko/nomad
1
0
Fork 0
mirror of https://github.com/kemko/nomad.git synced 2026-01-06 10:25:42 +03:00
Code Issues Packages Projects Releases Wiki Activity

doc: fix some typos in the "Guides" documentation

Browse Source
This commit is contained in:
Jonathan Ballet
2017-11-05 09:39:42 +01:00
parent 0b3476aabd
commit 9b48a2da72
5 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
website/source/guides/acl.html.markdown
View File

@@ -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:

2
website/source/guides/quotas.html.md
View File

@@ -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:

8
website/source/guides/securing-nomad.html.md
View File

@@ -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

2
website/source/guides/sentinel-policy.html.markdown
View File

@@ -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)

2
website/source/guides/sentinel/job.html.md
View File

@@ -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 |
| --------------------------------------- | ---------------------- |