-
Notifications
You must be signed in to change notification settings - Fork 114
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
Conversation
Vercel Previews Deployed
|
Broken Link CheckerNo broken links found! 🎉 |
boruszak
left a comment
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.
I left suggestions and my reasoning. Otherwise LGTM!
content/nomad/v1.11.x/content/docs/release-notes/nomad/v1-11-x.mdx
Outdated
Show resolved
Hide resolved
content/nomad/v1.11.x/content/docs/release-notes/nomad/v1-11-x.mdx
Outdated
Show resolved
Hide resolved
content/nomad/v1.11.x/content/docs/release-notes/nomad/v1-11-x.mdx
Outdated
Show resolved
Hide resolved
| [JSON Web Token (JWT)][] that has been signed by the leader's keyring and is | ||
| generated as part of the node's registration and heartbeat process. | ||
|
|
||
| The node identity feature is like multi-factor authentication for your Nomad |
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.
Do we want to call out that this is node introduction rather than identity? I see two different features and node identity does not act like MFA, it's node introduction that does.
If we wanted to expand the context, mTLS guards at the region level and stops misconfigured clients joining the wrong region or agents running in the wrong mode.
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.
Co-authored-by: Jeff Boruszak <[email protected]>
boruszak
left a comment
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.
See my comments about the overall workflow. I started just leaving suggestions, but after reading through the steps several times I'm not quite able to parse what is actually happening and why the ACL token is required.
|
|
||
| Follow these steps to use client node introduction tokens: | ||
|
|
||
| 1. [Create an ACL policy in which the node has write permissions](#create-an-acl-policy). |
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 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
| } | ||
| ``` | ||
|
|
||
| 1. Create the policy. |
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.
|
|
||
| ### Create an ACL role | ||
|
|
||
| This example creates an ACL role called `client-introduction`. |
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.
| -policy="client-introduction" | ||
| ``` | ||
|
|
||
| Output is similar to the this: |
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. |
| [`-client-intro-token` parameter](/nomad/commands/agent#client-intro-token) of | ||
| the `nomad agent` command. Alternately, you may place the `intro_token.jwt` file | ||
| in the client's state directory, which is by default [the | ||
| `<data_dir>/client_state_dir>` |
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?
|
|
||
| ```shell-session | ||
| Accessor ID = 8c22a7c0-44f5-044d-ef84-bfa06118faf4 | ||
| Secret ID = d99d678d-426c-330e-74f3-de53a868e2f9 |
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.
| ```shell-session | ||
| curl \ | ||
| --request POST \ | ||
| --header "X-Nomad-Token: d99d678d-426c-330e-74f3-de53a868e2f9" \ |
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?
| You may optionally specify node names, node pools, and TTLs when you generate | ||
| client introduction tokens. |
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?
boruszak
left a comment
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.
Much more clear to me this time, with the existing ACL token issue taken care of.
My big suggestion is to be more explicit about the change from working on the server node to working on the client node, which gets buried in the term "Nomad agent."
| You may restrict which clients join your cluster with a client | ||
| introduction token. The client node introduction feature is like multi-factor | ||
| authentication for your Nomad clusters. It does not replace mTLS but adds an | ||
| additional layer of security to prevent an unauthorized or misconfigured client | ||
| from joining a Nomad cluster. Although you do not need to configure mTLS to use | ||
| client node introduction tokens, we do recommend securing your cluster with mTLS. |
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.
| You may restrict which clients join your cluster with a client | |
| introduction token. The client node introduction feature is like multi-factor | |
| authentication for your Nomad clusters. It does not replace mTLS but adds an | |
| additional layer of security to prevent an unauthorized or misconfigured client | |
| from joining a Nomad cluster. Although you do not need to configure mTLS to use | |
| client node introduction tokens, we do recommend securing your cluster with mTLS. | |
| Use client introduction tokens to restrict which clients join your cluster. | |
| The client node introduction feature is like multi-factor authentication | |
| for your Nomad clusters. **It does not replace mTLS**, but instead adds an | |
| additional layer of security that prevents an unauthorized or misconfigured client | |
| from joining a Nomad cluster. |
Moving the last sentence to the next line. Changes to the first sentence simplify the sentence and main idea. Bold is optional. I believe it fits the style guidelines about emphasis for differentiation but not semantic emphasis.
| from joining a Nomad cluster. Although you do not need to configure mTLS to use | ||
| client node introduction tokens, we do recommend securing your cluster with mTLS. | ||
|
|
||
| Each security layer answers a distinct question: |
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.
| Each security layer answers a distinct question: | |
| You do not need to configure mTLS before you use client node introduction tokens. However, we do recommend securing your cluster with mTLS, even if you use a client introduction because each security layer answers a distinct question: |
I'm not a fan of the rhetorical questions, but if you keep them flesh out the setup to provide context.
| When you generate a client introduction token, you may specify the following | ||
| optional parameters: |
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.
| When you generate a client introduction token, you may specify the following | |
| optional parameters: | |
| Optionally, you can specify additional parameters for your client introduction token to further secure their cluster access: |
|
|
||
| - You have [bootstrapped the ACL system](/nomad/docs/secure/acl/bootstrap). | ||
| - You have a management token. | ||
| - You have configured the CLI to use the management token. |
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.
| - You have configured the CLI to use the management token. | |
| - You set the value of the management to `$NOMAD_TOKEN` to use the CLI. |
More actionable/direct by stating the env. variable.
| 1. [Configure the Nomad agent to use client introduction](#configure-the-nomad-agent). | ||
| 1. [Start the Nomad agent](#start-the-nomad-agent). |
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. [Configure the Nomad agent to use client introduction](#configure-the-nomad-agent). | |
| 1. [Start the Nomad agent](#start-the-nomad-agent). | |
| 1. [Update the Nomad server's configuration to use client introduction tokens](#update-the-nomad-server). | |
| 1. [Start the Nomad agent on the client node](#start-the-nomad-agent). |
You've mentioned previously the terminology blur around "Nomad server" and "Nomad agent." I suggest differentiating with the phrasing here because it's the only part of these instructions where there's lingering ambiguity around a sudden change. All of the previous steps interact with the Nomad server, and then you start the agent on the client node with the token attached.
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.
You aren't starting the agent on the client node. The agent in question is the server.
| "eyJhbGciOiJSUzI1NiIsImtpZCI6IjljZDgy..." | ||
| ``` | ||
|
|
||
| ### Configure the Nomad agent |
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.
| ### Configure the Nomad agent | |
| ### Update the Nomad server's configuration |
|
|
||
| </CodeBlockConfig> | ||
|
|
||
| There is no additional client configuration. |
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.
| There is no additional client configuration. | |
| This example also sets default and max TTLs for the client introduction token. | |
| No additional configuration is required on the client node. |
To be more explicit about the other parameters in the example.
Description
Enhance the client node intro and identity release note with content from Benjamin Lykins' blog. This builds on the previous PR that added the bit about not replacing mTLS.
Links
Jira: CE-1084 CE-1088
Contributor checklists
Review urgency:
Pull request:
Content:
Reviewer checklist