* UI: Part 1 - hds adoption replace <Modal> (#23363) * replace policy-form modal * replace clients/attribution modal * clients/config modal * scope form odal * remove button type * include toolbar to match other example templates * rotate credentials modal * add toolbar button class for hds buttons * transformation-edit modal * add back test selector * add route arg to button! * update link status * fix link-status tests * remove prevent default * update db tests * update tests * use page alert for hcp link status banner * fix scopy button selector * fix sidebar test * change to neutral banner * UI: Part 2 - hds adoption replace <Modal> (#23398) * upgrade HDS library (adds support for snippet containers * cleanup flight icons * replace transit key action modals * re-add deps as devDeps * remove line * address transit tests * UI: Part 3 - hds adoption replace <Modal> (#23415) * cleanup css * cleanup extra type attr * masked input download modal * use Hds::Button in download button" * fix size of modal * tiny icon fix * refactor download button to always render download icon * update tests * UI: Part 3.5 - hds adoption replace <Modal> (#23448) * replication-promote modal * replication component modals * replication add secondary modal * move update text for diff * UI: Part 4 - hds adoption replace <Modal> (#23451) * k8 configure modal * kv delete modal * ldap modals * pki modals * add trash icon * move deps * UI: Part 5 - hds adoption replace <Modal> (#23471) * replace confirmation modals --------- * UI: Part 6 - hds adoption replace <Modal> (#23484) * search select with modal * policy search select modal * replace date dropdown for client dashboard * change padding to top * update policy example args * lolllll test typo wow * update dropdown tests * shamir flow modals! * add one more container * update test selectors * UI: Final hds adoption replace <Modal> cleanup PR (#23522) * search select with modal * policy search select modal * replace date dropdown for client dashboard * change padding to top * update policy example args * lolllll test typo wow * update dropdown tests * shamir flow modals! * add one more container * update test selectors * remove wormhole and modal component * fix selectors * uninstall wormhole * remove shamir-modal-flow class * fix confirm modal test * fix pki and kv test * fix toolbar selector kv * client and download button test * fix-confirmation-modal-padding * fix replication modal tests so relevant modal opens (#23540) * more confirmation modal tests * adds changelog
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
POST
requests 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 thePOST
request. For example:POST pki/generate/root/:type
creates a new self-signed CA certificate (an issuer) and private key, which is only returned iftype = exported
POST pki/issuer/:issuer_ref/sign-intermediate
creates a certificate, and returns issuing CA and CA chain data that is only available once
The
pki/action
adapter is used to map the desired action to the corresponding endpoint, and thepki/action
serializer 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
parsedCertificate
attribute 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
enabled
andinterval_duration
which are reserved for auto-tidy operations only.pki/tidy-status
does 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
findRecord
andupdateRecord
in thepki/tidy.js
adapter only interact with the/config/auto-tidy
endpoint. For each manual tidy operation, a new record is created so onsave()
the model uses thecreateRecord
method which only ever uses the/tidy
endpoint.
The following models more closely follow a CRUD pattern:
-
pki/issuer
Issuers are created by the
pki/action
model by either importing a CA or generating a root -
pki/role
-
pki/key