From e155b85c15080847cfa1cee744c2fde0d170ced5 Mon Sep 17 00:00:00 2001 From: stephengaudet Date: Thu, 17 Aug 2023 16:20:58 -0700 Subject: [PATCH 1/5] update gcp kms vault native authentication --- docs/gcp_kms.md | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/docs/gcp_kms.md b/docs/gcp_kms.md index 53c83869..c4c2aeb9 100644 --- a/docs/gcp_kms.md +++ b/docs/gcp_kms.md @@ -54,19 +54,31 @@ The key-ring name and location are required in the signatory configuration. ## **Application Access:** -The below steps are for providing signatory with the permissions to access the google cloud account Key Management. +Providing Signatory with the permissions to access GCP KMS will differ depending on whether or not Signatory is running inside or outside of GCP. +One thing that each method has in common is the creation of a Service Account: * Select `IAM & ADMIN` from the menu and select `Service accounts`. Create a new service account or use an existing one with all the above permissions (Get, Sign & Import) granted. -* Select the created/existing service account and within that create a new key and a prompt to download the application credentials will appear, select the JSON format. -* The downloaded JSON file is needed in signatory config or can be assigned to the below environment variable. -## **Environment variables** +### **Authenticating with the Service Account from outside GCP:** -`cloudkms` backend accepts GCP's standard `GOOGLE_APPLICATION_CREDENTIALS` environment variable +* Select the created/existing service account and within that create a new key and a prompt to download the application credentials will appear, select the JSON format. +* The downloaded JSON file is needed in signatory config or can be assigned to the below environment variable. ```sh export GOOGLE_APPLICATION_CREDENTIALS="signatory-testing-a7sdfew625aecb.json" ``` +### **Authenticating with the Service Account from a GCP VM:** + +With Signatory running within GCP, there is no need to download the service account credentials and place them on Signatory's file system. Instead, simply edit the VM specification's for `Identity and API access` such that it has selected the aforementioned Service Account. + +### **Authenticating with the Service Account from a GKE pod:** + +Again, with Signatory running within GCP, there is no need to download the service account credentials and place them on Signatory's file system. Best practice in this scenario is to [use Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) In short: + +- enable Workload Identity on the cluster +- create a kubernetes Service Account and bind it to the aforementioned IAM Service Account +- annotate the kubernetes Service Account with the email address of the IAM Service Account +- update the pod spec to include the `serviceAccountName` field, this is the name of the kubernetes Service Account and redeploy the pod ## **Getting a PKH** From 1a37b48aa2cd89a5ecc6bdef422387385ba06e99 Mon Sep 17 00:00:00 2001 From: stephengaudet Date: Thu, 17 Aug 2023 17:29:00 -0700 Subject: [PATCH 2/5] remove unnecessary words --- docs/gcp_kms.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/docs/gcp_kms.md b/docs/gcp_kms.md index c4c2aeb9..900cca89 100644 --- a/docs/gcp_kms.md +++ b/docs/gcp_kms.md @@ -67,18 +67,19 @@ One thing that each method has in common is the creation of a Service Account: ```sh export GOOGLE_APPLICATION_CREDENTIALS="signatory-testing-a7sdfew625aecb.json" ``` -### **Authenticating with the Service Account from a GCP VM:** -With Signatory running within GCP, there is no need to download the service account credentials and place them on Signatory's file system. Instead, simply edit the VM specification's for `Identity and API access` such that it has selected the aforementioned Service Account. +### **Authenticating with the Service Account from GCP VM:** -### **Authenticating with the Service Account from a GKE pod:** +No need to download the service account credentials and place them on Signatory's file system, and no use of `GOOGLE_APPLICATION_CREDENTIALS` env var. Instead, edit the VM specifications for `Identity and API access` such that it selects the IAM Service Account. -Again, with Signatory running within GCP, there is no need to download the service account credentials and place them on Signatory's file system. Best practice in this scenario is to [use Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) In short: +### **Authenticating with the Service Account from GKE pod:** -- enable Workload Identity on the cluster -- create a kubernetes Service Account and bind it to the aforementioned IAM Service Account -- annotate the kubernetes Service Account with the email address of the IAM Service Account -- update the pod spec to include the `serviceAccountName` field, this is the name of the kubernetes Service Account and redeploy the pod +No need to download the service account credentials and place them on Signatory's file system, and no use of `GOOGLE_APPLICATION_CREDENTIALS` env var. Best practice is to [use Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) In short: + +* enable Workload Identity on the cluster +* create a kubernetes Service Account and bind it to the IAM Service Account +* annotate the kubernetes Service Account with the email address of the IAM Service Account +* update the pod spec to include the `serviceAccountName` field, this is the name of the kubernetes Service Account and redeploy the pod ## **Getting a PKH** From 87fd0e00b80f1a2e2fb76a9c1a8a6bb928c09d6d Mon Sep 17 00:00:00 2001 From: stephengaudet Date: Thu, 17 Aug 2023 17:34:29 -0700 Subject: [PATCH 3/5] remove unnecessary words --- docs/gcp_kms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/gcp_kms.md b/docs/gcp_kms.md index 900cca89..97acf154 100644 --- a/docs/gcp_kms.md +++ b/docs/gcp_kms.md @@ -79,7 +79,7 @@ No need to download the service account credentials and place them on Signatory' * enable Workload Identity on the cluster * create a kubernetes Service Account and bind it to the IAM Service Account * annotate the kubernetes Service Account with the email address of the IAM Service Account -* update the pod spec to include the `serviceAccountName` field, this is the name of the kubernetes Service Account and redeploy the pod +* update the pod spec to include the `serviceAccountName` field, this is the name of the kubernetes Service Account ## **Getting a PKH** From 148bc099327527261a27e667ba3bef04a81cf588 Mon Sep 17 00:00:00 2001 From: stephengaudet Date: Thu, 17 Aug 2023 17:44:13 -0700 Subject: [PATCH 4/5] remove unnecessary words --- docs/gcp_kms.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/gcp_kms.md b/docs/gcp_kms.md index 97acf154..9ebf06d0 100644 --- a/docs/gcp_kms.md +++ b/docs/gcp_kms.md @@ -70,11 +70,11 @@ export GOOGLE_APPLICATION_CREDENTIALS="signatory-testing-a7sdfew625aecb.json" ### **Authenticating with the Service Account from GCP VM:** -No need to download the service account credentials and place them on Signatory's file system, and no use of `GOOGLE_APPLICATION_CREDENTIALS` env var. Instead, edit the VM specifications for `Identity and API access` such that it selects the IAM Service Account. +Do not download the service account credentials and place them on Signatory's file system, and do not use `GOOGLE_APPLICATION_CREDENTIALS` env var. Instead, edit the VM specifications for `Identity and API access` such that it selects the IAM Service Account. ### **Authenticating with the Service Account from GKE pod:** -No need to download the service account credentials and place them on Signatory's file system, and no use of `GOOGLE_APPLICATION_CREDENTIALS` env var. Best practice is to [use Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) In short: +Do not download the service account credentials and place them on Signatory's file system, and do not use `GOOGLE_APPLICATION_CREDENTIALS` env var. Best practice is to [use Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) In short: * enable Workload Identity on the cluster * create a kubernetes Service Account and bind it to the IAM Service Account From a38aae0d6a4b7c51c2d98312a5bfbcd0785a59ff Mon Sep 17 00:00:00 2001 From: stephengaudet Date: Fri, 18 Aug 2023 08:59:22 -0700 Subject: [PATCH 5/5] distinguish the IAM Service Account --- docs/gcp_kms.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/gcp_kms.md b/docs/gcp_kms.md index 9ebf06d0..590a287d 100644 --- a/docs/gcp_kms.md +++ b/docs/gcp_kms.md @@ -54,8 +54,8 @@ The key-ring name and location are required in the signatory configuration. ## **Application Access:** -Providing Signatory with the permissions to access GCP KMS will differ depending on whether or not Signatory is running inside or outside of GCP. -One thing that each method has in common is the creation of a Service Account: +Providing Signatory with the permissions to access GCP KMS will differ depending on whether or not Signatory is running inside or outside of GCP. +One thing that each method has in common is creation of the IAM Service Account: * Select `IAM & ADMIN` from the menu and select `Service accounts`. Create a new service account or use an existing one with all the above permissions (Get, Sign & Import) granted.