-
Notifications
You must be signed in to change notification settings - Fork 112
Nomad Docs: Enhance client intro release note & add usage guide #1384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
54d5a35
478ee33
f012113
a97b115
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -11,13 +11,16 @@ description: |- | |||||||||
| In order to create a Nomad cluster out of individual nodes, you need to | ||||||||||
| introduce them to one another. There are several ways to perform this: | ||||||||||
|
|
||||||||||
| - Manually | ||||||||||
| - Manual bootstrap | ||||||||||
| - Cloud Auto-Join | ||||||||||
| - Consul | ||||||||||
|
|
||||||||||
| This tutorial describes each method and provides configuration snippets, which | ||||||||||
| This guide describes each method and provides configuration snippets, which | ||||||||||
| you can use as starting points for your own configuration. | ||||||||||
|
|
||||||||||
| You may also use client node introduction tokens to restrict which clients join | ||||||||||
| your cluster. | ||||||||||
|
|
||||||||||
| ## Manual clustering | ||||||||||
|
|
||||||||||
| Manually bootstrapping a Nomad cluster does not rely on additional tooling, but | ||||||||||
|
|
@@ -82,9 +85,9 @@ the client. This means only one server must be specified because, after initial | |||||||||
| contact, the full set of servers in the client's region are shared with the | ||||||||||
| client. | ||||||||||
|
|
||||||||||
| ## Join nodes using cloud auto-join | ||||||||||
| ## Use cloud auto-join | ||||||||||
|
|
||||||||||
| As of Nomad 0.8.4, [`retry_join`] accepts a unified interface using the | ||||||||||
| The [`retry_join`] parameter accepts a unified interface using the | ||||||||||
| [go-discover] library for doing automatic cluster joining using cloud metadata. | ||||||||||
| To use retry-join with a supported cloud provider, specify the configuration on | ||||||||||
| the command line or configuration file as a `key=value key=value ...` string. | ||||||||||
|
|
@@ -214,6 +217,221 @@ consul { | |||||||||
| Refer to the [`consul` stanza] documentation for the complete set of configuration | ||||||||||
| options. | ||||||||||
|
|
||||||||||
|
|
||||||||||
| ## Use client node introduction tokens | ||||||||||
|
|
||||||||||
| You may restrict which clients join your cluster by configuring client | ||||||||||
| introduction tokens. The client node introduction feature is like multi-factor | ||||||||||
| authentication for your Nomad clusters. It does not replace mTLS but adds a | ||||||||||
| second layer of security to prevent an unauthorized or misconfigured client from | ||||||||||
| joining a Nomad cluster. | ||||||||||
|
|
||||||||||
| Each layer answers a distinct question: | ||||||||||
|
|
||||||||||
| - mTLS: Does the client have valid certificates for the cluster? | ||||||||||
| - Client introduction token: Does the client have a valid token to join the | ||||||||||
| cluster? | ||||||||||
|
|
||||||||||
| You do not need to configure mTLS to use client node introduction tokens, but we | ||||||||||
| do recommend securing your cluster with mTLS. | ||||||||||
|
|
||||||||||
| You may optionally specify node names, node pools, and TTLs when you generate | ||||||||||
| client introduction tokens. | ||||||||||
|
|
||||||||||
| Follow these steps to use client node introduction tokens: | ||||||||||
aimeeu marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
|
||||||||||
| 1. [Create an ACL policy in which the node has write permissions](#create-an-acl-policy). | ||||||||||
|
||||||||||
| 1. [Create an ACL policy in which the node has write permissions](#create-an-acl-policy). | |
| 1. [Create an ACL policy for a node with write permissions](#create-an-acl-policy). |
Simplifying this
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 1. Create the policy. | |
| 1. Add the policy to the Nomad cluster. |
To avoid repetition with the step before this one and clarify what is happening.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| This example creates an ACL role called `client-introduction`. | |
| Create an ACL role, and attach the policy you created to the role. | |
| This example creates an ACL role with the name `client-introduction` that uses the policy `client-introduction`. |
- Instructions to begin the section, then the example.
- Trying to point out both CLI flags because the example uses the same name but that isn't a requirement.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Output is similar to the this: | |
| The output describes the ACL role, including its attached policies and the Raft index at its creation. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Highlighting the value of the client-intro-token-1 ACL token, which all instructions up to this point have led to creating.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the client-intro-token-1 ACL token value. So now I have a few questions.
- Should the CLI instructions have included a step to use the ACL token as well?
- Are you supposed to create a separate ACL token for each node, and that's why it's
token-1? - Or should you be creating a separate intro token for each client, using the one shared ACL token?
But now I'm confused about the workflow. You create an ACL token so that a client node has permission to contact a server and change policies (which covers creating client introduction tokens). Then the node uses the client introduction token it creates to join the cluster it already has a valid ACL token from? Why the dedicated client token, then, when there's already an ACL token being used?
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing and/or extra bracket?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth stating our stance being that we should specify node names and node pool when creating an identity token to tightly scope and provide more security?