mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-10-29 17:52:32 +00:00
website: fix usages of img tag (#14910)
* fix usages of img tag and integrate dev-portal workflows * Adjust Makefile
This commit is contained in:
Bryce Kalow
2
website/.gitignore
vendored
2
website/.gitignore
vendored
@@ -7,3 +7,5 @@ out
|
||||
# As per Next.js conventions (https://nextjs.org/docs/basic-features/environment-variables#default-environment-variables)
|
||||
.env*.local
|
||||
!.env*
|
||||
|
||||
website-preview
|
||||
|
||||
@@ -1,56 +1,38 @@
|
||||
.DEFAULT_GOAL := website
|
||||
|
||||
PWD=$$(pwd)
|
||||
DOCKER_IMAGE="hashicorp/dev-portal"
|
||||
DOCKER_IMAGE_LOCAL="dev-portal-local"
|
||||
DOCKER_RUN_FLAGS=-it \
|
||||
--publish "3000:3000" \
|
||||
--rm \
|
||||
--tty \
|
||||
--volume "$(PWD)/content:/app/content" \
|
||||
--volume "$(PWD)/public:/app/public" \
|
||||
--volume "$(PWD)/data:/app/data" \
|
||||
--volume "$(PWD)/redirects.js:/app/redirects.js" \
|
||||
--volume "next-dir:/app/website-preview/.next" \
|
||||
--volume "$(PWD)/.env:/app/.env" \
|
||||
-e "REPO=vault"
|
||||
|
||||
# Default: run this if working on the website locally to run in watch mode.
|
||||
.PHONY: website
|
||||
website:
|
||||
@echo "==> Downloading latest Docker image..."
|
||||
@docker pull hashicorp/vault-website
|
||||
@echo "==> Starting website in Docker..."
|
||||
@docker run \
|
||||
--interactive \
|
||||
--rm \
|
||||
--tty \
|
||||
--workdir "/website" \
|
||||
--volume "$(shell pwd):/website" \
|
||||
--volume "/website/node_modules" \
|
||||
--publish "3000:3000" \
|
||||
hashicorp/vault-website \
|
||||
npm start
|
||||
@docker pull $(DOCKER_IMAGE)
|
||||
@echo "==> Starting website..."
|
||||
@docker run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE)
|
||||
|
||||
# This command will generate a static version of the website to the "out" folder.
|
||||
build:
|
||||
@echo "==> Downloading latest Docker image..."
|
||||
@docker pull hashicorp/vault-website
|
||||
@echo "==> Starting build in Docker..."
|
||||
@docker run \
|
||||
--interactive \
|
||||
--rm \
|
||||
--tty \
|
||||
--workdir "/website" \
|
||||
--volume "$(shell pwd):/website" \
|
||||
--volume "/website/node_modules" \
|
||||
hashicorp/vault-website \
|
||||
npm run static
|
||||
# Use this if you have run `website/build-local` to use the locally built image.
|
||||
.PHONY: website/local
|
||||
website/local:
|
||||
@echo "==> Starting website from local image..."
|
||||
@docker run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE_LOCAL)
|
||||
|
||||
# If you are changing node dependencies locally, run this to generate a new
|
||||
# local Docker image with the dependency changes included.
|
||||
build-image:
|
||||
@echo "==> Building Docker image..."
|
||||
@docker build -t hashicorp-vault-website-local .
|
||||
# Run this to generate a new local Docker image.
|
||||
.PHONY: website/build-local
|
||||
website/build-local:
|
||||
@echo "==> Building local Docker image"
|
||||
@docker build https://github.com/hashicorp/dev-portal.git\#main \
|
||||
-t $(DOCKER_IMAGE_LOCAL)
|
||||
|
||||
# Use this if you have run `build-image` to use the locally built image
|
||||
# rather than our CI-generated image to test dependency changes.
|
||||
website-local:
|
||||
@echo "==> Downloading latest Docker image..."
|
||||
@docker pull hashicorp/vault-website
|
||||
@echo "==> Starting website in Docker..."
|
||||
@docker run \
|
||||
--interactive \
|
||||
--rm \
|
||||
--tty \
|
||||
--workdir "/website" \
|
||||
--volume "$(shell pwd):/website" \
|
||||
--volume "/website/node_modules" \
|
||||
--publish "3000:3000" \
|
||||
hashicorp-vault-website-local \
|
||||
npm start
|
||||
|
||||
.DEFAULT_GOAL := website
|
||||
.PHONY: build build-image website website-local
|
||||
|
||||
@@ -6,15 +6,15 @@ description: Guide to partnership integrations and creating plugins for Vault.
|
||||
|
||||
# Vault Integration Program
|
||||
|
||||
The HashiCorp Vault Integration Program allows for partners to integrate their products to work with HashiCorp Vault (Open Source or Enterprise versions) or [HashiCorp Cloud Platform](https://cloud.hashicorp.com) (HCP) Vault. Vault covers a relatively large surface area and thereby a large set of possible integrations, some of which require the partner to build a Vault plugin or an integration that results in the partner’s solution working tightly with Vault.
|
||||
The HashiCorp Vault Integration Program allows for partners to integrate their products to work with HashiCorp Vault (Open Source or Enterprise versions) or [HashiCorp Cloud Platform](https://cloud.hashicorp.com) (HCP) Vault. Vault covers a relatively large surface area and thereby a large set of possible integrations, some of which require the partner to build a Vault plugin or an integration that results in the partner’s solution working tightly with Vault.
|
||||
|
||||
Partners integrating their solutions via the Vault Integration Process provide their customers a verified and seamless user experience.
|
||||
Partners integrating their solutions via the Vault Integration Process provide their customers a verified and seamless user experience.
|
||||
|
||||
This program is intended to be largely a self-service process with links and guidance to information sources, clearly defined steps, and checkpoints.
|
||||
|
||||
## Types of Vault Integrations
|
||||
|
||||
Vault is an Identity-based security solution that leverages trusted sources of identity to keep secrets and application data secured with one centralized, audited workflow for tightly controlling access to secrets across applications, systems, and infrastructure while encrypting data both in flight and at rest. For a full description of the current features please refer to the Vault [website](/).
|
||||
Vault is an Identity-based security solution that leverages trusted sources of identity to keep secrets and application data secured with one centralized, audited workflow for tightly controlling access to secrets across applications, systems, and infrastructure while encrypting data both in flight and at rest. For a full description of the current features please refer to the Vault [website](/).
|
||||
|
||||
Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. This means the plugin process does not share the same memory space as Vault and therefore can only access the interfaces and arguments given to it.
|
||||
|
||||
@@ -26,27 +26,40 @@ The diagram below depicts the key Vault integration categories and types.
|
||||
|
||||
Main Vault categories for partners to integrate with include:
|
||||
|
||||
**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models to better support your business use case. You can find more information about Vault Auth Methods [here](/docs/auth/).
|
||||
**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models to better support your business use case. You can find more information about Vault Auth Methods [here](/docs/auth/).
|
||||
|
||||
**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing customer deployments of Vault and the partner’s solution.
|
||||
|
||||
HSM (Hardware Security Module) are specific types of runtime integrations and provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol, thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault's HSM support [here](/docs/enterprise/hsm).
|
||||
|
||||
-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
|
||||
-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
|
||||
|
||||
**Audit/Monitoring & Compliance**: Audit/Monitoring and Compliance are components in Vault that keep a detailed log of all requests and responses to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors. Vault supports multiple audit devices to support your business use case. You can find more information about Vault Audit Devices [here](/docs/audit/).
|
||||
|
||||
**Secrets Engines**: Secrets engines are plugin components which store, generate, or encrypt data. Secrets engines are provided with some set of data that perform actions on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, and secrets engines connect to other services. Examples of secrets engines include identity modules of Cloud providers like AWS, Azure IAM models, Cloud (LDAP), database or key management. You can find more information about Vault secrets engines [here](/docs/secrets/).
|
||||
|
||||
### HCP Vault
|
||||
|
||||
HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault.
|
||||
|
||||
Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](https://learn.hashicorp.com/collections/vault/cloud) learn guide for quickly getting started.
|
||||
Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](https://learn.hashicorp.com/collections/vault/cloud) learn guide for quickly getting started.
|
||||
|
||||
### Vault Integration Badges
|
||||
There are two types of badges that partners could receive: Vault Enterprise Verified and HCP Vault Verified badges. Partners will be issued the Vault Enterprise badge for integrations that work with Vault Enterprise features such as namespaces, HSM support, or key management. Partners will be issued the HCP Vault badge once their integration has been verified to work with HCP Vault. The badge(s) would be displayed on their partner page (example: [MongoDB](https://www.hashicorp.com/partners/tech/mongodb#vault) and can also be used on their own website to help provide better visibility and differentiation to customers. The process for verification of these integrations is detailed below.
|
||||
|
||||
<span style={{display:'block', textAlign:'center'}}><img src="/img/VaultEnterprise_badge.png" style={{width:'200px', height:'200px'}}/><img src="/img/HCPV_badge.png" style={{width:'200px', height:'200px'}}/></span>
|
||||
There are two types of badges that partners could receive: Vault Enterprise Verified and HCP Vault Verified badges. Partners will be issued the Vault Enterprise badge for integrations that work with Vault Enterprise features such as namespaces, HSM support, or key management. Partners will be issued the HCP Vault badge once their integration has been verified to work with HCP Vault. The badge(s) would be displayed on their partner page (example: [MongoDB](https://www.hashicorp.com/partners/tech/mongodb#vault) and can also be used on their own website to help provide better visibility and differentiation to customers. The process for verification of these integrations is detailed below.
|
||||
|
||||
<span style={{display:'block', textAlign:'center'}}>
|
||||
<ImageConfig inline height={200} width={200}>
|
||||
|
||||
|
||||
|
||||
</ImageConfig>
|
||||
<ImageConfig inline height={200} width={200}>
|
||||
|
||||
|
||||
|
||||
</ImageConfig>
|
||||
</span>
|
||||
|
||||
## Development Process
|
||||
|
||||
@@ -84,7 +97,7 @@ We encourage partners to closely follow the above guidance. Adopting the same st
|
||||
|
||||
### 3. Develop and Test
|
||||
|
||||
For our partners who are building runtime integrations with Vault, we encourage them to support multiple [authentication](/docs/auth) methods (e.g. Approle, JWT, K8s) besides tokens. Additionally we encourage them to add as much flexibility when specifying paths for secrets engines. For our partners who want to build a plugin, the only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go-Language, HashiCorp has found the integration development process to be straightforward and simple when partners pay close attention and follow the resources by adopting the same structure and coding patterns to help expedite the review and release cycles.
|
||||
For our partners who are building runtime integrations with Vault, we encourage them to support multiple [authentication](/docs/auth) methods (e.g. Approle, JWT, K8s) besides tokens. Additionally we encourage them to add as much flexibility when specifying paths for secrets engines. For our partners who want to build a plugin, the only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go-Language, HashiCorp has found the integration development process to be straightforward and simple when partners pay close attention and follow the resources by adopting the same structure and coding patterns to help expedite the review and release cycles.
|
||||
|
||||
Please remember that all integrations should have the appropriate documentation to assist Vault users in configuring the integrations.
|
||||
|
||||
@@ -114,11 +127,13 @@ Please remember that all integrations should have the appropriate documentation
|
||||
|
||||
The process to spin up a testing instance of HCP Vault is very [straightforward](https://learn.hashicorp.com/tutorials/cloud/get-started-vault). HCP has been designed as a turn-key managed service so configuration is minimal. Furthermore, HashiCorp provides all new users an initial credit which lasts for a couple of months when using the [development](https://cloud.hashicorp.com/pricing/vault) cluster. Used in conjunction with AWS free tier resources, there should be no cost beyond the time spent by the designated tester.
|
||||
|
||||
There are a couple of items to consider when determining if the integration will work with HCP Vault.
|
||||
There are a couple of items to consider when determining if the integration will work with HCP Vault.
|
||||
|
||||
- Since HCP Vault is running Vault Enterprise, the integration will need to be aware of [Namespaces](https://learn.hashicorp.com/tutorials/vault/namespaces). This is important as the main namespace in HCP Vault is called 'admin' which is different from the standard ‘root’ namespace in a self managed Vault instance. If the integration currently doesn't support namespaces, then an additional benefit of adding Namespace support iis that this will also enable it to work with all self managed Vault Enterprise installations.
|
||||
- HCP Vault is currently only deployed on AWS and so the partner’s application should be able to be deployed or run in AWS. This is vital so that HCP Vault is able to communicate with the application using a [private peered](https://learn.hashicorp.com/tutorials/cloud/amazon-peering-hcp) connection via a [HashiCorp Virtual Network](https://cloud.hashicorp.com/docs/hcp/network).
|
||||
- HCP Vault is currently only deployed on AWS and so the partner’s application should be able to be deployed or run in AWS. This is vital so that HCP Vault is able to communicate with the application using a [private peered](https://learn.hashicorp.com/tutorials/cloud/amazon-peering-hcp) connection via a [HashiCorp Virtual Network](https://cloud.hashicorp.com/docs/hcp/network).
|
||||
|
||||
Additional resources:
|
||||
|
||||
- [HCP Sign up](https://cloud.hashicorp.com/docs/hcp/network)
|
||||
- [Namespaces - Vault Enterprise](/docs/enterprise/namespaces)
|
||||
- [Create a Vault Cluster on HCP | HashiCorp Learn](https://learn.hashicorp.com/tutorials/cloud/get-started-vault)
|
||||
@@ -133,7 +148,7 @@ Once the integration has been verified, the partner is requested to sign the Has
|
||||
|
||||
### 5. Release
|
||||
|
||||
At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration.
|
||||
At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration.
|
||||
|
||||
For Auth or Secret Engine plugins specifically, once the plugin has been validated by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
const withHashicorp = require('@hashicorp/platform-nextjs-plugin')
|
||||
const redirects = require('./redirects.next')
|
||||
const redirects = require('./redirects')
|
||||
|
||||
// log out our primary environment variables for clarity in build logs
|
||||
console.log(`HASHI_ENV: ${process.env.HASHI_ENV}`)
|
||||
|
||||
@@ -61,7 +61,7 @@
|
||||
"directory": "website"
|
||||
},
|
||||
"scripts": {
|
||||
"build": "next build",
|
||||
"build": "./scripts/website-build.sh",
|
||||
"dynamic": "NODE_ENV=production next build && next start",
|
||||
"export": "next export",
|
||||
"format": "next-hashicorp format",
|
||||
@@ -70,7 +70,7 @@
|
||||
"linkcheck": "linkcheck https://www.vaultproject.io",
|
||||
"lint": "next-hashicorp lint",
|
||||
"postinstall": "simple-git-hooks",
|
||||
"start": "next-remote-watch './content/**/*.mdx'",
|
||||
"start": "./scripts/website-start.sh",
|
||||
"static": "npm run build && npm run export && cp _redirects out/."
|
||||
},
|
||||
"simple-git-hooks": {
|
||||
|
||||
31
website/scripts/website-build.sh
Executable file
31
website/scripts/website-build.sh
Executable file
@@ -0,0 +1,31 @@
|
||||
# Repo which we are cloning and executing npm run build:deploy-preview within
|
||||
REPO_TO_CLONE=dev-portal
|
||||
# Set the subdirectory name for the base project
|
||||
PREVIEW_DIR=website-preview
|
||||
# The directory we want to clone the project into
|
||||
CLONE_DIR=website-preview
|
||||
# The product for which we are building the deploy preview
|
||||
PRODUCT=vault
|
||||
|
||||
from_cache=false
|
||||
|
||||
if [ -d "$PREVIEW_DIR" ]; then
|
||||
echo "$PREVIEW_DIR found"
|
||||
CLONE_DIR="$PREVIEW_DIR-tmp"
|
||||
from_cache=true
|
||||
fi
|
||||
|
||||
# Clone the base project, if needed
|
||||
echo "⏳ Cloning the $REPO_TO_CLONE repo, this might take a while..."
|
||||
git clone --depth=1 "https://github.com/hashicorp/$REPO_TO_CLONE.git" "$CLONE_DIR"
|
||||
|
||||
if [ "$from_cache" = true ]; then
|
||||
echo "Setting up $PREVIEW_DIR"
|
||||
cp -R "./$CLONE_DIR/." "./$PREVIEW_DIR"
|
||||
fi
|
||||
|
||||
# cd into the preview directory project
|
||||
cd "$PREVIEW_DIR"
|
||||
|
||||
# Run the build:deploy-preview start script
|
||||
REPO=$PRODUCT DEV_IO=$PRODUCT IS_CONTENT_PREVIEW=true HASHI_ENV=project-preview npm run build:deploy-preview
|
||||
25
website/scripts/website-start.sh
Executable file
25
website/scripts/website-start.sh
Executable file
@@ -0,0 +1,25 @@
|
||||
# Repo which we are cloning and executing npm run build:deploy-preview within
|
||||
REPO_TO_CLONE=dev-portal
|
||||
# Set the subdirectory name for the dev-portal app
|
||||
PREVIEW_DIR=website-preview
|
||||
# The product for which we are building the deploy preview
|
||||
PRODUCT=vault
|
||||
|
||||
should_pull=true
|
||||
|
||||
# Clone the dev-portal project, if needed
|
||||
if [ ! -d "$PREVIEW_DIR" ]; then
|
||||
echo "⏳ Cloning the $REPO_TO_CLONE repo, this might take a while..."
|
||||
git clone --depth=1 https://github.com/hashicorp/$REPO_TO_CLONE.git "$PREVIEW_DIR"
|
||||
should_pull=false
|
||||
fi
|
||||
|
||||
cd "$PREVIEW_DIR"
|
||||
|
||||
# If the directory already existed, pull to ensure the clone is fresh
|
||||
if [ "$should_pull" = true ]; then
|
||||
git pull origin main
|
||||
fi
|
||||
|
||||
# Run the dev-portal content-repo start script
|
||||
REPO=$PRODUCT PREVIEW_DIR="$PREVIEW_DIR" npm run start:local-preview
|
||||
Reference in New Issue
Block a user