-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
UI: allow navigation to subdirectory #22436
UI: allow navigation to subdirectory #22436
Conversation
@@ -49,7 +49,7 @@ | |||
</:toolbarActions> | |||
</KvPageHeader> | |||
|
|||
{{#if (not-eq @secret.state "destroyed")}} | |||
{{#if (and (not this.emptyState) (not-eq @secret.state "destroyed"))}} |
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.
small styling fix I noticed
Build Results: |
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.
Big improvement with a little code. Nice work!
* Use Hashicorp docker proxy for CI docker images * Use library/consul as the mirror path instead of hashicorp/consul - Looks like the older 1.4.4 image was not published within the hashicorp/consul space, only newer images are. - Switch to library/consul which seems to have both versions
- The Golang ACME library will retry on failures until the passed in context times out. So if a test is broken it will never end until the context expires. - The timeouts are rather large to avoid some issues with slow CI runners, that have already triggered on a nightly 32 bit run
Signed-off-by: Alexander Scheel <[email protected]>
* Add 502 to Vault uninitialized * Update index.mdx * Update index.mdx --------- Co-authored-by: Violet Hynes <[email protected]>
- Allow us to call and apply an issuer's leaf_not_after_behavior to a leaf certificate from various locations.
Fix article usage Co-authored-by: Violet Hynes <[email protected]>
* options => opts * Standardise receiver letter, specify interface
…ne (#22266) * add sink wrapper to take telemetry measures * make use of sinkwrapper
* Refactor sign-intermediate API response - Allow the sign-intermediate response handling code to be shared across different API calls. * Add missing cieps.go
…d Proxy) (#22264) * VAULT-14644 first draft of changes for WIF support * VAULT-14644 Potentially finalize Agent work for WIF support * VAULT-14644 finishing touches * VAULT-14644 finishing touches * VAULT-14644 remove extra log * VAULT-14644 better docs * VAULT-14644 changelog * VAULT-14644 review feedback
Update includes dependency upgrades and WIF support --------- Co-authored-by: hc-github-team-secure-vault-ecosystem <[email protected]>
* Add ADP requirement callout Add a callout to the top of the page to note that this feature requires Vault ENT + ADP * rephrase * Update website/content/docs/enterprise/pkcs11-provider/index.mdx --------- Co-authored-by: Violet Hynes <[email protected]>=
* Major overhaul of `vault operator generate-root` CLI help Resolves #15252 A major overhaul of the `vault operator generate-root` CLI help to surface the fact that it is actually six separate commands in one, rather than requiring users to independently deduce this mental model themselves. In the process of doing so, also standardize some terminology: * Fix places which used the phrase "operational token" instead of "operation token" to be consistent with the prevailing terminology. * Fix places which used the phrase "recovery operation token" instead of "recovery token" to be consistent with the prevailing terminology. This PR currently focusses on the CLI help, but following review and feedback, I assume I'll need to replicate many of the same changes in website/content/docs/commands/operator/generate-root.mdx as well. * Fix some tab characters which should have been spaces * Update command/operator_generate_root.go --------- Co-authored-by: Violet Hynes <[email protected]>
#22160) * replaced each instance of MaskedInput in PKI with CertificateCard * modify tests for pki-generate-csr * add test for pki-issuer-details. modify test for pki-certificate-details * added test for pki-key-details. modified test for pki-sign-intermediate-form * update 2 test helper files and modify test for pki-issuer-rotate-root * update test for certificate-card-test.js, update test for the kubernetes configuration-test.js * modify pki-action-forms-test.js to no longer look for masked input. expand test for pki-issuer-details-test.js to check for all issuer details * change CertificateCard to show different format types (PEM, DER, nothing) depending on the value provided. update 2 test files to account for this. * change CertificateCard arg name from @certficateValue to @DaTa to be more inclusive of different uses of CertificateCard (i.e when used for a private key, not a certificate). add description to certificate-card.js * change naming for attr.options.masked to attr.options.displayCard to reflect the change from MaskedInput to CertificateCard * add changelog * change attribute to isCertificate to better fit the title of the component CertificateCard. edit pki-certificate-details.hbs to get rid of extraneous code
* fluent generation of client count testing data input * godocs * add VerifyInput and complete testing * pr fixes * pr fixes * buf lint
…#21132) * add entry and intent log * test for intent logs
Co-authored-by: Violet Hynes <[email protected]>
* documenting missing option * added comment about setting to zero
- Remove the omitempty flag from issuer_ref, and add it to the warnings and error fields
* Add kv engine to tsconfig paths * Add kv-breadcrumb util to kv engine * remove lib/kv-breadcrumbs and use kv-engine util instead * Fix tests
rebase bonk up, closing in favor of #22455 |
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.
Will finish reviewing the other content updates on Monday
- `password` `(string: <required>)` – The password for the LDAP user. | ||
When authenticating with the Vault CLI, i.e. `vault login -method=ldap username=mitchellh` |
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.
- `password` `(string: <required>)` – The password for the LDAP user. | |
When authenticating with the Vault CLI, i.e. `vault login -method=ldap username=mitchellh` | |
- `password` `(string: <required>)` – Password for the LDAP user authenticating with the Vault CLI. |
When a role is not explicitly specified, behavior is specified by the | ||
`default_directory_policy` in the [ACME configuration](#set-acme-configuration). | ||
These directories can also be forbidden by setting that policy as `forbid`. If | ||
the policy is `sign-verbatim` then _any_ identifier for which the client can | ||
prove ownership of will be issued for. This is similar to using the | ||
[Sign Verbatim](#sign-verbatim) endpoint, but with additional verification | ||
that the client has proven ownership (within the ACME protocol) of the | ||
requested certificate identifiers. When `external-policy` is specified as the | ||
default value, the CIEPS engine <EnterpriseAlert inline="true" /> is used for | ||
validating and templating the certificate instead of a role; ACME's challenge | ||
validation is still enforced. An optional policy name can be specified by using | ||
`external-policy:policy`. Roles are not used when CIEPS is used. |
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 a role is not explicitly specified, behavior is specified by the | |
`default_directory_policy` in the [ACME configuration](#set-acme-configuration). | |
These directories can also be forbidden by setting that policy as `forbid`. If | |
the policy is `sign-verbatim` then _any_ identifier for which the client can | |
prove ownership of will be issued for. This is similar to using the | |
[Sign Verbatim](#sign-verbatim) endpoint, but with additional verification | |
that the client has proven ownership (within the ACME protocol) of the | |
requested certificate identifiers. When `external-policy` is specified as the | |
default value, the CIEPS engine <EnterpriseAlert inline="true" /> is used for | |
validating and templating the certificate instead of a role; ACME's challenge | |
validation is still enforced. An optional policy name can be specified by using | |
`external-policy:policy`. Roles are not used when CIEPS is used. | |
When a role is not explicitly specified, Vault uses the default policy set by | |
`default_directory_policy` in the [ACME configuration](#set-acme-configuration): | |
- `forbid`: denies access to the directory | |
- `sign-verbatim`: allows access to clients that provide *any* identifier | |
they can prove ownership for. `sign-verbatim` behaves like the | |
[Sign Verbatim](#sign-verbatim) endpoint but with the additional verification | |
that the client can prove ownership within the ACME protocol of the requested | |
certificate identifiers. | |
- `external-policy`: <EnterpriseAlert inline="true" /> uses the CIEPS engine to | |
validate and template the certificate instead of a role with ACME challenge | |
validation. You can specify an optional policy name with `external-policy:policy`. | |
Roles are not used when CIEPS is used. |
Style correction: write in active voice, make options scannable
Similar to the [generate certificate and key](#generate-certificate-and-key) | ||
endpoint, this endpoint generate key material and certificate via an external | ||
policy engine. The private key material stays local to Vault, with the external | ||
service getting only an empty CSR. Any parameters passed to this endpoint are | ||
passed verbatim to the CIEPS engine <EnterpriseAlert inline="true" />. The | ||
response format is the same between both endpoints. |
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.
Similar to the [generate certificate and key](#generate-certificate-and-key) | |
endpoint, this endpoint generate key material and certificate via an external | |
policy engine. The private key material stays local to Vault, with the external | |
service getting only an empty CSR. Any parameters passed to this endpoint are | |
passed verbatim to the CIEPS engine <EnterpriseAlert inline="true" />. The | |
response format is the same between both endpoints. | |
Similar to the [generate certificate and key](#generate-certificate-and-key) | |
endpoint, this endpoint generate key material and certificate via an external | |
policy engine. The private key material stays local to Vault, with the external | |
service getting only an empty CSR. Any parameters passed to this endpoint are | |
passed verbatim to the CIEPS engine <EnterpriseAlert inline="true" />. The | |
response format is the same between both endpoints. | |
``````suggestion | |
Similar to the [generate certificate and key](#generate-certificate-and-key) | |
endpoint, the external policy endpoint generates key material and certificate | |
through an external policy engine. The private key material stays local to | |
Vault and the external service receives an empty CSR. All parameters passed | |
to the endpoint are passed, verbatim, to the CIEPS engine <EnterpriseAlert inline="true" />. | |
The response format is the same between both endpoints. |
Style correction: simplify language, write in active voice
It is suggested to limit access to the path-overridden issue endpoint (on | ||
`/pki/issuer/:issuer_ref/external-policy/issue/:policy`) and let the CIEPS | ||
engine override the issuer as necessary. |
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.
It is suggested to limit access to the path-overridden issue endpoint (on | |
`/pki/issuer/:issuer_ref/external-policy/issue/:policy`) and let the CIEPS | |
engine override the issuer as necessary. | |
We recommend you limit access to the path-overridden issue endpoint (on | |
`/pki/issuer/:issuer_ref/external-policy/issue/:policy`) and let the CIEPS | |
engine override the issuer as necessary. |
Style correction: active voice
Hi @schavis - sorry you got pinged on this! This was the result of rebase chaos and those commits aren't actually part of my PR. I attempted closing this PR before anyone could start reviewing - but you were too quick! 🙈 |
This partially fixes the request here #5362 so users can
LIST
at the secret level in the UI.Fixes #20563 and #13188 and #20563
The user in the gif has the following policy where they can only
LIST
at themy-secret/
level. Previously a user had to know the full secret path to view this list of secrets, now they just need the top-level secret path:If a user can only list metadata at the top level, so with a policy that looks something like:
The input in the card pre-fills with the path selected from the list view
