From 4cffe22f288afe0b3b2e07420d1a502d37091ede Mon Sep 17 00:00:00 2001 From: temp Date: Tue, 5 Apr 2022 16:58:07 -0400 Subject: [PATCH 1/2] no-op commit due to failed cherry-picking From c5b87f0eb36b78ccc47f6313766fe47ca613cc25 Mon Sep 17 00:00:00 2001 From: Bryce Kalow Date: Tue, 5 Apr 2022 15:57:37 -0500 Subject: [PATCH 2/2] website: fix usages of img tag (#14910) * fix usages of img tag and integrate dev-portal workflows * Adjust Makefile --- website/.gitignore | 2 + website/Makefile | 80 ++++++++------------- website/content/docs/partnerships.mdx | 39 ++++++---- website/next.config.js | 2 +- website/package.json | 4 +- website/{redirects.next.js => redirects.js} | 0 website/scripts/website-build.sh | 31 ++++++++ website/scripts/website-start.sh | 25 +++++++ 8 files changed, 119 insertions(+), 64 deletions(-) rename website/{redirects.next.js => redirects.js} (100%) create mode 100755 website/scripts/website-build.sh create mode 100755 website/scripts/website-start.sh diff --git a/website/.gitignore b/website/.gitignore index f93e0e403322..adaccf90dbaa 100644 --- a/website/.gitignore +++ b/website/.gitignore @@ -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 diff --git a/website/Makefile b/website/Makefile index 7d24096d2745..5e2815dec8a0 100644 --- a/website/Makefile +++ b/website/Makefile @@ -1,56 +1,38 @@ -# Default: run this if working on the website locally to run in watch mode. -website: - @echo "==> Downloading latest Docker image..." - @docker pull hashicorp/vault-website - @echo "==> Starting website in Docker..." - @docker run \ - --interactive \ +.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 \ - --workdir "/website" \ - --volume "$(shell pwd):/website" \ - --volume "/website/node_modules" \ - --publish "3000:3000" \ - hashicorp/vault-website \ - npm start + --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" -# This command will generate a static version of the website to the "out" folder. -build: +# 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 build in Docker..." - @docker run \ - --interactive \ - --rm \ - --tty \ - --workdir "/website" \ - --volume "$(shell pwd):/website" \ - --volume "/website/node_modules" \ - hashicorp/vault-website \ - npm run static + @docker pull $(DOCKER_IMAGE) + @echo "==> Starting website..." + @docker run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE) -# 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 . +# 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) -# 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 +# 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) -.DEFAULT_GOAL := website -.PHONY: build build-image website website-local diff --git a/website/content/docs/partnerships.mdx b/website/content/docs/partnerships.mdx index 187b288e6abf..38b65755eb9b 100644 --- a/website/content/docs/partnerships.mdx +++ b/website/content/docs/partnerships.mdx @@ -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. - +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. + + + + +![Vault Enterprise Badge](/img/VaultEnterprise_badge.png) + + + + +![HCP Vault](/img/HCPV_badge.png) + + + ## 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. diff --git a/website/next.config.js b/website/next.config.js index 266a76dd527c..e32022e3a7fb 100644 --- a/website/next.config.js +++ b/website/next.config.js @@ -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}`) diff --git a/website/package.json b/website/package.json index 5aa95fe15ceb..91b1713c6218 100644 --- a/website/package.json +++ b/website/package.json @@ -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": { diff --git a/website/redirects.next.js b/website/redirects.js similarity index 100% rename from website/redirects.next.js rename to website/redirects.js diff --git a/website/scripts/website-build.sh b/website/scripts/website-build.sh new file mode 100755 index 000000000000..8c1e50a6a08e --- /dev/null +++ b/website/scripts/website-build.sh @@ -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 diff --git a/website/scripts/website-start.sh b/website/scripts/website-start.sh new file mode 100755 index 000000000000..9fe4618df1ca --- /dev/null +++ b/website/scripts/website-start.sh @@ -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