diff --git a/website/content/docs/secrets/aws.mdx b/website/content/docs/secrets/aws.mdx index 23702c2d32..3e1ee58473 100644 --- a/website/content/docs/secrets/aws.mdx +++ b/website/content/docs/secrets/aws.mdx @@ -53,68 +53,143 @@ Most secrets engines must be configured in advance before they can perform their functions. These steps are usually completed by an operator or configuration management tool. -1. Enable the AWS secrets engine: +Enable the AWS secrets engine: - ```text - $ vault secrets enable aws - Success! Enabled the aws secrets engine at: aws/ - ``` + - By default, the secrets engine will mount at the name of the engine. To - enable the secrets engine at a different path, use the `-path` argument. + -1. Configure the credentials that Vault uses to communicate with AWS to generate - the IAM credentials: +```shell-session +$ vault secrets enable gcp +Success! Enabled the gcp secrets engine at: gcp/ +``` - ```text - $ vault write aws/config/root \ - access_key=AKIAJWVN5Z4FOFT7NLNA \ - secret_key=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 \ - region=us-east-1 - ``` +By default, the secrets engine will mount at the name of the engine. To +enable the secrets engine at a different path, use the `-path` argument. - Internally, Vault will connect to AWS using these credentials. As such, - these credentials must be a superset of any policies which might be granted - on IAM credentials. Since Vault uses the official AWS SDK, it will use the - specified credentials. You can also specify the credentials via the standard - AWS environment credentials, shared file credentials, or IAM role/ECS task - credentials. (Note that you can't authorize vault with IAM role credentials if you plan - on using STS Federation Tokens, since the temporary security credentials - associated with the role are not authorized to use GetFederationToken.) + - In some cases, you cannot set sensitive IAM security credentials in your - Vault configuration. For example, your organization may require that all - security credentials are short-lived or explicitly tied to a machine identity. - - To provide IAM security credentials to Vault, we recommend using Vault - [plugin workload identity federation](#plugin-workload-identity-federation-wif) - (WIF). + - ~> **Notice:** Even though the path above is `aws/config/root`, do not use - your AWS root account credentials. Instead, generate a dedicated user or - role. +![Partial screenshot of the Vault GUI showing the "Identity token key" search select input](/img/gui/aws/identityTokenKey.png) -1. Alternatively, configure the audience claim value and the role ARN to assume for plugin workload identity federation: +You must have `list` permission on the `identity/oidc/key` endpoint to view +existing workload identity federation (WIF) identity token keys during setup. - ```text - $ vault write aws/config/root \ - identity_token_audience="" \ - role_arn="" - ``` +1. Open the web UI for your Vault instance. +1. Login under the target namespace or choose the target namespace from the + selector at the bottom of the left-hand menu and re-authenticate. +1. Select **Secrets Engines** from the left-hand menu. +1. Click **Enable new engine +** on the **Secrets Engines** page. +1. Select **AWS**. +1. Click **Next**. +1. Set the mount path for the AWS plugin. For example, `aws`. +1. If you use WIF, add the identity token key: + - Click **Method Options**. + - Click **Identity Token Key**. + - Enter your new key name or select one from the token key list. +1. Click **Enable engine**. +1. Click **Save** to enable the plugin. - Vault's identity token provider will internally sign the plugin identity token JWT. - Given a trust relationship is configured between Vault and AWS via - Web Identity Federation, the secrets engine can exchange this identity token to obtain - ephemeral STS credentials. + - ~> **Notice:** For this trust relationship to be established, AWS must have an - an [IAM OIDC identity provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) - configured with information about the fully qualified and network-reachable - Issuer URL for Vault's plugin [identity token provider](/vault/api-docs/secret/identity/tokens#read-plugin-identity-well-known-configurations). - This is to ensure that AWS can fetch the JWKS [public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys) - and verify the plugin identity token signature. To configure Vault's Issuer, - please refer to the Identity Tokens - [documentation](/vault/api-docs/secret/identity/tokens#configure-the-identity-tokens-backend) + + +Configure the credentials that Vault uses to communicate with AWS to generate the IAM credentials: + + + + + +```shell-session +$ vault write aws/config/root \ + access_key=AKIAJWVN5Z4FOFT7NLNA \ + secret_key=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 \ + region=us-east-1 +``` + + + + + +![Partial screenshot of the Vault GUI showing the Configuration form](/img/gui/aws/configure.png) + +1. Open the web UI for your Vault instance. +1. Login under the target namespace or choose the target namespace from the + selector at the bottom of the left-hand menu and re-authenticate. +1. Select **Secrets Engines** from the left-hand menu. +1. Select your `aws` plugin you want to update. +1. Click **Configure**. +1. Enter your configuration information. +1. Set the access type +1. Save your changes. + + + + + +Internally, Vault will connect to AWS using these credentials. As such, +these credentials must be a superset of any policies which might be granted +on IAM credentials. Since Vault uses the official AWS SDK, it will use the +specified credentials. You can also specify the credentials via the standard +AWS environment credentials, shared file credentials, or IAM role/ECS task +credentials. (Note that you can't authorize vault with IAM role credentials if you plan +on using STS Federation Tokens, since the temporary security credentials +associated with the role are not authorized to use GetFederationToken.) + +In some cases, you cannot set sensitive IAM security credentials in your +Vault configuration. For example, your organization may require that all +security credentials are short-lived or explicitly tied to a machine identity. + +To provide IAM security credentials to Vault, we recommend using Vault +[plugin workload identity federation](#plugin-workload-identity-federation-wif) +(WIF). + +~> **Notice:** Even though the path above is `aws/config/root`, do not use +your AWS root account credentials. Instead, generate a dedicated user or +role. + +Alternatively, configure the audience claim value and the role ARN to assume for plugin workload identity federation: + + + + + +```shell-session +$ vault write aws/config/root \ + identity_token_audience="" \ + role_arn="" +``` + + + + + +Select **Workload Identity Federation** for Access Type and enter the following information: +![Partial screenshot of the Vault GUI showing the Configuration form with WIF access type selected](/img/gui/aws/configure-wif.png) + +- **Issuer URL**: The fully qualified and network-reachable issuer URL for the Vault plugin identity token issuer. For example, `https://vault.example.com/v1/identity/oidc/plugins`. +- **Role ARN**: The ARN of the AWS IAM role to assume. +- **Identity token audience**: The audience claim value for the plugin identity tokens. This value must match the allowed audiences configured for the target Federated Identity Credential. + + + + + +## Role setup +Vault's identity token provider will internally sign the plugin identity token JWT. +Given a trust relationship is configured between Vault and AWS via +Web Identity Federation, the secrets engine can exchange this identity token to obtain +ephemeral STS credentials. + +~> **Notice:** For this trust relationship to be established, AWS must have an +an [IAM OIDC identity provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) +configured with information about the fully qualified and network-reachable +Issuer URL for Vault's plugin [identity token provider](/vault/api-docs/secret/identity/tokens#read-plugin-identity-well-known-configurations). +This is to ensure that AWS can fetch the JWKS [public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys) +and verify the plugin identity token signature. To configure Vault's Issuer, +please refer to the Identity Tokens +[documentation](/vault/api-docs/secret/identity/tokens#configure-the-identity-tokens-backend) 1. Configure a Vault role that maps to a set of permissions in AWS as well as an AWS credential type. When users generate credentials, they are generated diff --git a/website/content/docs/secrets/azure.mdx b/website/content/docs/secrets/azure.mdx index edd9dd3e35..6f704f0ebc 100644 --- a/website/content/docs/secrets/azure.mdx +++ b/website/content/docs/secrets/azure.mdx @@ -24,10 +24,10 @@ The password will be deleted when the lease is revoked. - You can configure the Azure secrets engine with the Vault API or - established environment variables such as `AZURE_CLIENT_ID` or - `AZURE_CLIENT_SECRET`. If you use both methods, note that - environment variables always take precedence over API values. +You can configure the Azure secrets engine with the Vault API or +established environment variables such as `AZURE_CLIENT_ID` or +`AZURE_CLIENT_SECRET`. If you use both methods, note that +environment variables always take precedence over API values. @@ -35,70 +35,147 @@ Most secrets engines must be configured in advance before they can perform their functions. These steps are usually completed by an operator or configuration management tool. -1. Enable the Azure secrets engine: +Enable the Azure secrets engine: - ```shell - $ vault secrets enable azure - Success! Enabled the azure secrets engine at: azure/ - ``` + - By default, the secrets engine will mount at the name of the engine. To - enable the secrets engine at a different path, use the `-path` argument. + -1. Configure the secrets engine with account credentials: +```shell-session +$ vault secrets enable azure +Success! Enabled the azure secrets engine at: azure/ +``` - ```shell - $ vault write azure/config \ - subscription_id=$AZURE_SUBSCRIPTION_ID \ - tenant_id=$AZURE_TENANT_ID \ - client_id=$AZURE_CLIENT_ID \ - client_secret=$AZURE_CLIENT_SECRET +By default, the secrets engine will mount at the name of the engine. To +enable the secrets engine at a different path, use the `-path` argument. - Success! Data written to: azure/config - ``` + - If you are running Vault inside an Azure VM with MSI enabled, `client_id` and - `client_secret` may be omitted. For more information on authentication, see the [authentication](#authentication) section below. + - In some cases, you cannot set sensitive account credentials in your - Vault configuration. For example, your organization may require that all - security credentials are short-lived or explicitly tied to a machine identity. +![Partial screenshot of the Vault GUI showing the "Identity token key" search select input](/img/gui/azure/identityTokenKey.png) - To provide managed identity security credentials to Vault, we recommend using Vault - [plugin workload identity federation](#plugin-workload-identity-federation-wif) - (WIF) as shown below. +You must have `list` permission on the `identity/oidc/key` endpoint to view +existing workload identity federation (WIF) identity token keys during setup. -1. Alternatively, configure the audience claim value and the Client, Tenant and Subscription IDs for plugin workload identity federation: +1. Open the web UI for your Vault instance. +1. Login under the target namespace or choose the target namespace from the + selector at the bottom of the left-hand menu and re-authenticate. +1. Select **Secrets Engines** from the left-hand menu. +1. Click **Enable new engine +** on the **Secrets Engines** page. +1. Select **Azure**. +1. Click **Next**. +1. Set the mount path for the Azure plugin. For example, `azure`. +1. If you use WIF, add the identity token key: + - Click **Method Options**. + - Click **Identity Token Key**. + - Enter your new key name or select one from the token key list. +1. Click **Enable engine**. +1. Click **Save** to enable the plugin. - ```text - $ vault write azure/config \ - subscription_id=$AZURE_SUBSCRIPTION_ID \ - tenant_id=$AZURE_TENANT_ID \ - client_id=$AZURE_CLIENT_ID \ - identity_token_audience=$TOKEN_AUDIENCE - ``` + - The Vault identity token provider signs the plugin identity token JWT internally. - If a trust relationship exists between Vault and Azure through WIF, the secrets - engine can exchange the Vault identity token for a federated access token. + - To configure a trusted relationship between Vault and Azure: +Configure the secrets engine with account credentials: - - You must configure the [identity token issuer backend](/vault/api-docs/secret/identity/tokens#configure-the-identity-tokens-backend) - for Vault. - - Azure must have a - [federated identity credential](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#configure-a-federated-identity-credential-on-an-app) - configured with information about the fully qualified and network-reachable - issuer URL for the Vault plugin - [identity token provider](/vault/api-docs/secret/identity/tokens#read-plugin-identity-well-known-configurations). + - Establishing a trusted relationship between Vault and Azure ensures that Azure - can fetch JWKS - [public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys) - and verify the plugin identity token signature. + -1. Configure a role. A role may be set up with either an existing service principal, or - a set of Azure roles that will be assigned to a dynamically created service principal. +```shell-session +$ vault write azure/config \ + subscription_id=$AZURE_SUBSCRIPTION_ID \ + tenant_id=$AZURE_TENANT_ID \ + client_id=$AZURE_CLIENT_ID \ + client_secret=$AZURE_CLIENT_SECRET + +Success! Data written to: azure/config +``` + + + + + +![Partial screenshot of the Vault GUI showing the Configuration form](/img/gui/azure/configure.png) + +1. Open the web UI for your Vault instance. +1. Login under the target namespace or choose the target namespace from the + selector at the bottom of the left-hand menu and re-authenticate. +1. Select **Secrets Engines** from the left-hand menu. +1. Select your `azure` plugin you want to update. +1. Click **Configure**. +1. Enter your configuration information. +1. Set the access type +1. Save your changes. + + + + + +If you are running Vault inside an Azure VM with MSI enabled, `client_id` and `client_secret` may be omitted. For more information on authentication, see the [authentication](#authentication) section below. + +In some cases, you cannot set sensitive account credentials in your Vault configuration. For example, your organization may require that all security credentials are short-lived or explicitly tied to a machine identity. + +To provide managed identity security credentials to Vault, we recommend using Vault +[plugin workload identity federation](#plugin-workload-identity-federation-wif) +(WIF) as shown below. + +Alternatively, configure the audience claim value and the Client, Tenant and Subscription IDs for plugin workload identity federation: + + + + + +```shell-session +$ vault write azure/config \ + subscription_id=$AZURE_SUBSCRIPTION_ID \ + tenant_id=$AZURE_TENANT_ID \ + client_id=$AZURE_CLIENT_ID \ + identity_token_audience=$TOKEN_AUDIENCE +``` + + + + + +For WIF configuration, select **Workload Identity Federation** for Access Type and enter the following information: + ![Partial screenshot of the Vault GUI showing the Configuration form with WIF access type selected](/img/gui/azure/configure-wif.png) + - **Subscription ID**: The ID of the Azure subscription. + - **Tenant ID**: The ID of the Azure Active Directory tenant. + - **Client ID**: The OAuth2 client id to connect to Azure. + - **Issuer URL**: The fully qualified and network-reachable issuer URL for the Vault plugin identity token issuer. For example, `https://vault.example.com/v1/identity/oidc/plugins`. + - **Identity token audience**: The audience claim value for the plugin identity tokens. This value must match the allowed audiences configured for the target Federated Identity Credential. Mutually exclusive with `client_secret`. + + + + + +The Vault identity token provider signs the plugin identity token JWT internally. +If a trust relationship exists between Vault and Azure through WIF, the secrets +engine can exchange the Vault identity token for a federated access token. + +To configure a trusted relationship between Vault and Azure: + +- You must configure the [identity token issuer backend](/vault/api-docs/secret/identity/tokens#configure-the-identity-tokens-backend) + for Vault. +- Azure must have a + [federated identity credential](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#configure-a-federated-identity-credential-on-an-app) + configured with information about the fully qualified and network-reachable + issuer URL for the Vault plugin + [identity token provider](/vault/api-docs/secret/identity/tokens#read-plugin-identity-well-known-configurations). + +Establishing a trusted relationship between Vault and Azure ensures that Azure +can fetch JWKS +[public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys) +and verify the plugin identity token signature. + +Configure a role. A role may be set up with either an existing service principal, or a set of Azure roles that will be assigned to a dynamically created service principal. + + + The Vault UI only supports Azure Secret engine configuration. You must use the + CLI/API for role configuration and credential rotation. + To configure a role called "my-role" with an existing service principal: diff --git a/website/content/docs/secrets/gcp.mdx b/website/content/docs/secrets/gcp.mdx index cc422bb232..1a86d47761 100644 --- a/website/content/docs/secrets/gcp.mdx +++ b/website/content/docs/secrets/gcp.mdx @@ -38,66 +38,142 @@ Most secrets engines must be configured in advance before they can perform their functions. These steps are usually completed by an operator or configuration management tool. -1. Enable the Google Cloud secrets engine: +Enable the Google Cloud secrets engine: - ```shell-session - $ vault secrets enable gcp - Success! Enabled the gcp secrets engine at: gcp/ - ``` + - By default, the secrets engine will mount at the name of the engine. To - enable the secrets engine at a different path, use the `-path` argument. + -1. Configure the secrets engine with account credentials, or leave blank or unwritten - to use Application Default Credentials. +```shell-session +$ vault secrets enable gcp +Success! Enabled the gcp secrets engine at: gcp/ +``` - ```shell-session - $ vault write gcp/config credentials=@my-credentials.json - Success! Data written to: gcp/config - ``` +By default, the secrets engine will mount at the name of the engine. To +enable the secrets engine at a different path, use the `-path` argument. - If you are running Vault from inside [Google Compute Engine][gce] or [Google - Kubernetes Engine][gke], the instance or pod service account can be used in - place of specifying the credentials JSON file. - For more information on authentication, see the [authentication section](#authentication) below. + - In some cases, you cannot set sensitive IAM security credentials in your - Vault configuration. For example, your organization may require that all - security credentials are short-lived or explicitly tied to a machine identity. + - To provide IAM security credentials to Vault, we recommend using Vault - [plugin workload identity federation](#plugin-workload-identity-federation-wif) - (WIF) as shown below. +![Partial screenshot of the Vault GUI showing the "Identity token key" search select input](/img/gui/gcp/identityTokenKey.png) +You must have `list` permission on the `identity/oidc/key` endpoint to view +existing workload identity federation (WIF) identity token keys during setup. -1. Alternatively, configure the audience claim value and the service account email to assume for plugin workload identity federation: +1. Open the web UI for your Vault instance. +1. Login under the target namespace or choose the target namespace from the + selector at the bottom of the left-hand menu and re-authenticate. +1. Select **Secrets Engines** from the left-hand menu. +1. Click **Enable new engine +** on the **Secrets Engines** page. +1. Select **Google Cloud**. +1. Click **Next**. +1. Set the mount path for the GCP plugin. For example, `gcp`. +1. If you use WIF, add the identity token key: + - Click **Method Options**. + - Click **Identity Token Key**. + - Enter your new key name or select one from the token key list. +1. Click **Enable engine**. +1. Click **Save** to enable the plugin. - ```text - $ vault write gcp/config \ - identity_token_audience="" \ - service_account_email="" - ``` + - Vault's identity token provider signs the plugin identity token JWT internally. - If a trust relationship exists between Vault and GCP through WIF, the secrets - engine can exchange the Vault identity token for a - [federated access token](https://cloud.google.com/docs/authentication/token-types#access). + - To configure a trusted relationship between Vault and GCP: - - You must configure the [identity token issuer backend](/vault/api-docs/secret/identity/tokens#configure-the-identity-tokens-backend) - for Vault. - - GCP must have a - [workload identity pool and provider](https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers) - configured with information about the fully qualified and network-reachable - issuer URL for the Vault plugin's - [identity token provider](/vault/api-docs/secret/identity/tokens#read-plugin-identity-well-known-configurations). +Configure the secrets engine with account credentials, or leave blank or unwritten to use Application Default Credentials: - Establishing a trusted relationship between Vault and GCP ensures that GCP - can fetch JWKS - [public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys) - and verify the plugin identity token signature. + -1. Configure rolesets or static accounts. See the relevant sections below. + + +```shell-session +$ vault write gcp/config credentials=@my-credentials.json +Success! Data written to: gcp/config +``` + + + + + +![Partial screenshot of the Vault GUI showing the Configuration form](/img/gui/gcp/configure.png) + +1. Open the web UI for your Vault instance. +1. Login under the target namespace or choose the target namespace from the + selector at the bottom of the left-hand menu and re-authenticate. +1. Select **Secrets Engines** from the left-hand menu. +1. Select your `gcp` plugin you want to update. +1. Click **Configure**. +1. Enter your configuration information. +1. Set the access type +1. Save your changes. + + + + + +If you are running Vault from inside [Google Compute Engine][gce] or [Google +Kubernetes Engine][gke], the instance or pod service account can be used in +place of specifying the credentials JSON file. +For more information on authentication, see the [authentication section](#authentication) below. + +In some cases, you cannot set sensitive IAM security credentials in your +Vault configuration. For example, your organization may require that all +security credentials are short-lived or explicitly tied to a machine identity. + +To provide IAM security credentials to Vault, we recommend using Vault +[plugin workload identity federation](#plugin-workload-identity-federation-wif) +(WIF) as shown below. + +Alternatively, configure the audience claim value and the service account email to assume for plugin workload identity federation: + + + + + +```shell-session +$ vault write gcp/config \ + identity_token_audience= \ + service_account_email= +``` + + + + + +Select **Workload Identity Federation** for Access Type and enter the following information: +![Partial screenshot of the Vault GUI showing the Configuration form with WIF access type selected](/img/gui/gcp/configure-wif.png) + +- **Issuer URL**: The fully qualified and network-reachable issuer URL for the Vault plugin identity token issuer. For example, `https://vault.example.com/v1/identity/oidc/plugins`. +- **Identity token audience**: The audience claim value for the plugin identity tokens. This value must match the allowed audiences configured for the target Federated Identity Credential. +- **Service account email**: Email ID for the Service Account to impersonate for Workload Identity Federation. + + + + + +Vault's identity token provider signs the plugin identity token JWT internally. +If a trust relationship exists between Vault and GCP through WIF, the secrets +engine can exchange the Vault identity token for a +[federated access token](https://cloud.google.com/docs/authentication/token-types#access). + +To configure a trusted relationship between Vault and GCP: +- You must configure the [identity token issuer backend](/vault/api-docs/secret/identity/tokens#configure-the-identity-tokens-backend) + for Vault. +- GCP must have a + [workload identity pool and provider](https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers) + configured with information about the fully qualified and network-reachable + issuer URL for the Vault plugin's + [identity token provider](/vault/api-docs/secret/identity/tokens#read-plugin-identity-well-known-configurations). + +Establishing a trusted relationship between Vault and GCP ensures that GCP +can fetch JWKS +[public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys) +and verify the plugin identity token signature. + + + The Vault UI only supports GCP Secret engine configuration. You must use the + CLI/API for additional operations. + ## Rolesets @@ -813,4 +889,4 @@ To upgrade: - Be aware of leftover leases from previous versions. While these old leases will still be revocable, they will not actually invalidate their associated - access token, and that token will still be useable for up to one hour. + access token, and that token will still be useable for up to one hour. \ No newline at end of file diff --git a/website/public/img/gui/aws/configure-wif.png b/website/public/img/gui/aws/configure-wif.png new file mode 100644 index 0000000000..f6ec738c2d Binary files /dev/null and b/website/public/img/gui/aws/configure-wif.png differ diff --git a/website/public/img/gui/aws/configure.png b/website/public/img/gui/aws/configure.png new file mode 100644 index 0000000000..3d3135787d Binary files /dev/null and b/website/public/img/gui/aws/configure.png differ diff --git a/website/public/img/gui/aws/identityTokenKey.png b/website/public/img/gui/aws/identityTokenKey.png new file mode 100644 index 0000000000..9100f54e1c Binary files /dev/null and b/website/public/img/gui/aws/identityTokenKey.png differ diff --git a/website/public/img/gui/azure/configure-wif.png b/website/public/img/gui/azure/configure-wif.png new file mode 100644 index 0000000000..d45644521c Binary files /dev/null and b/website/public/img/gui/azure/configure-wif.png differ diff --git a/website/public/img/gui/azure/configure.png b/website/public/img/gui/azure/configure.png new file mode 100644 index 0000000000..3dd2ac6271 Binary files /dev/null and b/website/public/img/gui/azure/configure.png differ diff --git a/website/public/img/gui/azure/identityTokenKey.png b/website/public/img/gui/azure/identityTokenKey.png new file mode 100644 index 0000000000..2c91453bdf Binary files /dev/null and b/website/public/img/gui/azure/identityTokenKey.png differ diff --git a/website/public/img/gui/gcp/configure-wif.png b/website/public/img/gui/gcp/configure-wif.png new file mode 100644 index 0000000000..73f65af82e Binary files /dev/null and b/website/public/img/gui/gcp/configure-wif.png differ diff --git a/website/public/img/gui/gcp/configure.png b/website/public/img/gui/gcp/configure.png new file mode 100644 index 0000000000..ecd1d5aba1 Binary files /dev/null and b/website/public/img/gui/gcp/configure.png differ diff --git a/website/public/img/gui/gcp/identityTokenKey.png b/website/public/img/gui/gcp/identityTokenKey.png new file mode 100644 index 0000000000..2caa245621 Binary files /dev/null and b/website/public/img/gui/gcp/identityTokenKey.png differ