This page collects brief definitions of some of the technical terms used in the documentation for HCP, HCP Consul, HCP Vault, and HCP Packer.
- Audit device log
- Base image
- Build fingerprint
- Downstream build
- Downstream image
- Golden image
- HCP Packer registry
- HCP Packer registry data source
- HCP Terraform provider
- Image bucket
- Image channel
- Intra Region
- Inter Region
- Major Version
- Minor Version
Upstream images that an image bucket depends on directly or indirectly as source images.
In HCP Packer, ancestry refers to the relationship between source images (parents) and their downstream child images. The HCP Packer UI can display ancestry statuses that warn you when an image was built from an old version of one or more ancestors. Refer to the Ancestry documentation for details.
Audit devices are the components in Vault that keep a detailed log of all requests and response to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors.
To learn more, go through the Access the audit log for troubleshooting section of the Vault Operation Tasks tutorial.
Base image is an industry term referring to an image that other images are built upon. For example, security teams may publish a base image that other teams in the organization must use as a starting point for their projects. This can also be referred to as a source image or parent image.
A build refers to the image metadata stored on the HCP Packer registry from all artifacts produced by a single builder. Each image has a creation date and an ID that references the remote location of the image artifact. Refer to the image metadata documentation for more details.
Downstream image is an industry term referring to an image that is built from a specific source image, For example, an image containing specific application software may be built on top of a security golden image. This is often also called a child image.
Downstream build is an industry term referring to an individual build that is based on artifacts from a specific, pre-existing build.
Entity represents a Vault client which has one or more aliases mapped. For example, a single user who has accounts in both GitHub and LDAP can be mapped to a single entity in Vault that has 2 aliases, one of type GitHub and one of type LDAP.
To learn more about entities, go through the Identity: Entities and Groups tutorial.
Golden image is an industry term referring to an image that should be used as the source for instance creation in infrastructure.
The HCP Packer registry is a service that stores metadata about your images, including when they were created, where the image exists in the cloud, and what (if any) git commit is associated with your image build. This bridges the gap between image factories and image deployments, allowing development and security teams to work together to create, manage, and consume golden images in a centralized way. Reference the HCP Packer registry docs for more details.
In the HCP Packer UI, the Registry is where you can view all of the image buckets in your organization.
The HCP Packer registry data source enables you to query the HCP Packer registry for an image to use as the source image to a Packer build. Data sources are new to Packer as of last year, and only available in HCL templates. Refer to the reference image metadata documentation for more details.
The HCP Terraform provider is the Terraform provider for HashiCorp Cloud Platform. Providers are plugins that allow Terraform to communicate with external APIs. The HCP Terraform provider includes the
hcp_packer_image data sources that you can use to query the HCP Packer registry for an image to use in a Terraform configuration. Refer to the reference image metadata documentation for more details.
HashiCorp Virtual Networks. It delegates an IPv4 CIDR (classless inter-domain routing) range to HCP which is then reflected on the cloud provider's virtual network CIDR range.
An image bucket is a container within the HCP Packer registry that stores image metadata from a single Packer template. Image buckets contain one or more iterations. Reference the image bucket documentation for more details.
Image channels assign HCP Packer registry iterations to human-readable names that consumers can reference in Packer templates and Terraform configurations. They allow consumers to automatically reference the correct image version on the registry without having to update their code. Refer to the image channels documentation for more details.
The resources are all located within the same cloud provider region.
The resources are located across the different cloud provider regions.
An iteration is an immutable record of each successful
packer build for a single template, stored on the HCP Packer registry. Each iteration may contain multiple builds, depending on how you configured sources in your template. Refer to the image metadata documentation for more details.
Vault releases major functionality and features in their major version releases. Examples of Vault major versions are 1.6, 1.7, etc.
Minor versions releases of Vault contain bug fixes and small enhancements that do not have an impact on backward compatibility. Minor versions are released more frequently than major releases and provide a safe upgrade path for users. Examples of minor versions include 1.6.0, 1.6.1, 1.7.0, etc.
Namespaces is a set of features within Vault Enterprise that allows Vault environments to support secure multi-tenancy within a Vault deployment.
To learn more, go through the following tutorials:
An organization is an entity in HCP that contains your resources, including HashiCorp Virtual Networks (HVN), registries, and server clusters. Organizations may also be referred to as tenants.
When a Vault server is started, it starts in a sealed state. In this state, Vault is configured to know where and how to access the physical storage, but doesn't know how to decrypt any of it. There is also an API to seal the Vault. This will throw away the master key in memory and require another unseal process to restore it. Sealing only requires a single operator with root privileges.
To learn more, go through the Seal the cluster section of the Vault Operation Tasks tutorial.
Vault enables users to take a snapshot of all Vault data. The snapshot can be used to restore Vault to the point in time when a snapshot was taken.
To learn more about snapshots, go through the Data snapshots section of the Vault Operation Tasks tutorial.
Tokens are the core method for authenticating with Vault. Within Vault, tokens map to information. The most important information mapped to a token is the policies. Vault policies control access to secrets.
To learn more about Vault tokens, go through the Vault Tokens tutorials.
Unsealing is the process of obtaining the plaintext master key necessary to read the decryption key to decrypt the data, allowing access to the Vault. Prior to unsealing, almost no operations are possible with Vault.
To learn more, go through the Unseal the cluster section of the Vault Operation Tasks tutorial.