Workflow identities currently support ACL policies being applied
to a job ID within a namespace. With this update an ACL policy
can be applied to a namespace. This results in the ACL policy
being applied to all jobs within the namespace.
This introduces a new HTTP endpoint (and an associated CLI command) for querying
ACL policies associated with a workload identity. It allows users that want
to learn about the ACL capabilities from within WI-tasks to know what sort of
policies are enabled.
---------
Co-authored-by: Tim Gross <tgross@hashicorp.com>
Co-authored-by: Aimee Ukasick <aimee.ukasick@hashicorp.com>
* action page
* change all page_title fields
* update title
* constraint through migrate pages
* update page title and heading to use sentence case
* fix front matter description
* Apply suggestions from code review
Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
---------
Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
Nomad Enterprise users operating in air-gapped or otherwise secured environments
don't want to send license reporting metrics directly from their
servers. Implement manual/offline reporting by periodically recording usage
metrics snapshots in the state store, and providing an API and CLI by which
cluster administrators can download the snapshot for review and out-of-band
transmission to HashiCorp.
This is the CE portion of the work required for implemention in the Enterprise
product. Nomad CE does not perform utilization reporting.
Ref: https://github.com/hashicorp/nomad-enterprise/pull/2673
Ref: https://hashicorp.atlassian.net/browse/NMD-68
Ref: https://go.hashi.co/rfc/nmd-210
The server startup could "hang" to the view of an operator if it
had a key that could not be decrypted or replicated loaded from
the FSM at startup.
In order to prevent this happening, the server startup function
will now use a timeout to wait for the encrypter to be ready. If
the timeout is reached, the error is sent back to the caller which
fails the CLI command. This bubbling of error message will also
flush to logs which will provide addition operator feedback.
The server only cares about keys loaded from the FSM snapshot and
trailing logs before the encrypter should be classed as ready. So
that the encrypter ready function does not get blocked by keys
added outside of the initial Raft load, we take a snapshot of the
decryption tasks as we enter the blocking call, and class these as
our barrier.
* Add note to root keyring remove command
This PR updates the documentation for the root keyring remove command to note that the full key ID must be provided for the command to function correctly.
* Move keyID explanation to usage section
---------
Co-authored-by: Aimee Ukasick <aimee.ukasick@hashicorp.com>
* Docs: 1.10 release notes and upgrade factoring
* Update based on code review suggestions
* add CLI for disabling UI URL hints
* fix indentation
* nav: list release notes in reverse order
fix broken link to v1.6.x docs
* Update PKCE section from Daniel's latest PR
* update pkce per daniel's suggestion
* Add dynamic host volumes governance section from blog
trying not to violate the principle of least astonishment.
we want to only auto-enable PKCE on *new* auth methods,
rather than *new or updated* auth methods, to avoid a
scenario where a Nomad admin updates an auth method
sometime in the future -- something innocent like a new
client secret -- and their OIDC provider doesn't like PKCE.
the main concern is that the provider won't like PKCE
in a totally confusing way. error messages rarely
say PKCE directly, so why the user's auth method
suddenly broke would be a big mystery.
this means that to enable it on existing auth methods,
you would set `OIDCDisablePKCE = false`, and the double-
negative doesn't feel right, so instead, swap the language,
so enabling it on *existing* methods reads sensibly, and to
disable it on *new* methods reads ok-enough:
`OIDCEnablePKCE = false`
* modify rawexec TaskConfig and Config to accept envvar denylist
* update rawexec driver docs to include deniedEnvars options
Co-authored-by: Daniel Bennett <dbennett@hashicorp.com>
---------
Co-authored-by: Daniel Bennett <dbennett@hashicorp.com>
* Docs: Fix broken links in main for 1.10 release
* Implement Tim's suggestions
* Remove link to Portworx from ecosystem page
* remove "Portworx" since Portworx 3.2 no longer supports Nomad
When using Nomad with Consul, each Nomad agent is expected to have a Consul
agent running alongside. When using Nomad Enterprise and Consul Enterprise
together, the Consul agent may be in a Consul admin partition. In order for
Nomad's "anti-entropy" sync to work with Consul, the Consul ACL token and ACL
policy for the Nomad client must be in the same admin partition as the Consul
agent. Otherwise, we can register services (via WI) but then won't be able to
deregister them unless they're the default namespace.
Ref: https://hashicorp.atlassian.net/browse/NET-12361
Describe the built-in `mkdir` plugin in the plugin concepts docs in a little
more detail. Crosslink to there from the `plugin_id` field docs, and clarify
that the `mkdir` plugin doesn't support the capacity request fields.
Update the example plugins to avoid using volume author controlled variables in
favor of Nomad-controlled ones, to reduce the risk of path traversal, and
explain to plugin authors they'll likely want to avoid this in their own
plugins.
When configuring Consul to use Nomad workload identities, you create the Consul
auth method in the default namespace. If you're using Consul Enterprise
namespaces, there are two available approaches: one is to create the tokens in
the default namespace and give them policies that define cross-namespace access,
and the other is to use binding rules that map the login to a particular
namespace. The latter is what we show in our docs, but this was missing a note
that any roles (and their associated policies) targetted by `-bind-type role`
need to exist in the Consul namespace we're logging into.
Also, in Nomad CE, the `consul.namespace` flag is always treated as having been set to
`"default"`. That is, we ignore it and don't return an error even though it's a
Nomad ENT-only feature. Clarify this in the documentation for the field the same
way we've done for the `cluster` field.
Co-authored-by: Aimee Ukasick <aimee.ukasick@hashicorp.com>
