* UI: HDS adoption replace AlertBanner part 1 (#21163) * rename test selector * replace db banner * add class * replace db role edit * db creds * generate creds * simpler class * license banner component * oidc callback plash * raft * aws * secret create or update * change to compact alert for form field * change back to inline * combine alert banners * wrap in conditional * remove references to message class * UI: HDS adoption replace AlertBanner part 2 (#21243) * token expire warning * delete css * edit form * item details distribute mfa step 2 transit verify * back to secondary * distribute * oidc lease error * sign * kv obj and repl dash * more repl * update test selector * show, creds * shamir * pki csr * pki banners * add hds library to ember engines * woops comma * fix k8 test * update message error component for last! * hold off MessageError changes until next pr * revert test selectors * update pki tests * UI: part 3 remove alert banner (#21334) * final component swap * and actual final of MessageError * update MessageError selectors * delete alert-banner and remove references * update next step alerts to highlight color * finishing touches, auth form test and client dashboard inline link * fix more selectors * fix shamir flow test * ui: part 4 final cleanup (#21365) * replace AlertPopup * add test tag * move tag * one more message error tag * delete alert popup * final css cleanup * move preformatted flash into <p> tag * ui: address comments for sidebranch (#21388) * add periods, move link to trailing * more periods and typo fix
Vault PKI
Welcome to the Vault PKI (Ember) Engine! Below is an overview of PKI and resources for how to get started working within this engine.
About PKI
Public Key Infrastructure (PKI) is a system of processes, technologies, and policies that allows you to encrypt and sign data. (source: digicert.com)
The Vault PKI Secrets Engine allows security engineers to create a chain of PKI certificates much easier than they would with traditional workflows.
About the UI engine
If you couldn't tell from the documentation above, PKI is complex. As such, the data doesn't map cleanly to a CRUD model and so the first thing you might notice is that the models and adapters for PKI (which live in the main app, not the engine) have some custom logic that differentiate it from most other secret engines. Below are the models used throughout PKI and how they are used to interact with the mount. Aside from pki/action, each model has a corresponding tab in the UI that takes you to its LIST view.
-
pki/action
This model is used to perform different
POSTrequests that receive similar parameters but don't create a single item (which would be a record in Ember data). These various actions may create multiple items that contain different attributes than those submitted in thePOSTrequest. For example:POST pki/generate/root/:typecreates a new self-signed CA certificate (an issuer) and private key, which is only returned iftype = exportedPOST pki/issuer/:issuer_ref/sign-intermediatecreates a certificate, and returns issuing CA and CA chain data that is only available once
The
pki/actionadapter is used to map the desired action to the corresponding endpoint, and thepki/actionserializer includes logic to send the relevant attributes. The following PKI workflows use this model: -
pki/certificate/base
This model is for specific interactions with certificate data. The base model contains attributes that make up a certificate's content. The other models that extend this model certificate/generate and certificate/sign include additional attributes to perform their relevant requests.
The
parsedCertificateattribute is an object that houses all of the parsed certificate data returned by the parse-pki-cert.js util. -
pki/tidy
This model is used to manage tidy operations in a few different contexts. All of the following endpoints share the same parameters except
enabledandinterval_durationwhich are reserved for auto-tidy operations only.pki/tidy-statusdoes not use an Ember data model because it is read-onlyPOST pki/tidy- perform a single, manual tidy operationPOST pki/config/auto-tidy- set configuration for automating the tidy processGET pki/config/auto-tidy- read auto-tidy configuration settings
The auto-tidy config is the only data that persists so
findRecordandupdateRecordin thepki/tidy.jsadapter only interact with the/config/auto-tidyendpoint. For each manual tidy operation, a new record is created so onsave()the model uses thecreateRecordmethod which only ever uses the/tidyendpoint.
The following models more closely follow a CRUD pattern:
-
pki/issuer
Issuers are created by the
pki/actionmodel by either importing a CA or generating a root -
pki/role
-
pki/key