I'm trying to run Vault CSI provider but I'm getting the following error in my app pod:
MountVolume.SetUp failed for volume "secrets-store-inline" : rpc error: code = Unknown desc = failed to mount secrets store objects for pod vault/my-service-9b78df688-8xnql, err: rpc error: code = Unknown desc = error making mount request: failed to login: Error making API request. Namespace: vault URL: POST https://vault.craft-code.com/v1/auth/gcp/login Code: 400. Errors: * unable to get public key for signed JWT: unable to get public key "xxxxx" for JWT subject "system:serviceaccount:vault:service-web-app": googleapi: Error 400: Request contains an invalid argument.
According to the doc, before login to vault google cloud should issue jwt credential to be able to login in vault. I'm ussing terraform but I don't know how to do that. Could something explain it?
Once the service account and key have been created, the private key can be used to generate the JWT token needed to login to Vault.
To configure a Google Cloud service account to issue a JWT token before it can be used to login to Vault, you need to complete the following steps:
Create a service account in the Google Cloud platform.
Download the JSON key file associated with the service account.
Configure the Vault server to use the GCP auth backend and provide
the JSON key file for the service account.
Configure the Google Cloud IAM roles for the service account in order
to grant it access to the Vault server.
Get the JWT token from the service account and use it to authenticate
with Vault.
Refer to this doc also
Related
gcloud auth list
Credentialed Accounts ACTIVE ACCOUNT
* xxxx#xxxx.com
To set the active account, run:
$ gcloud config set account `ACCOUNT
The credentials used here are correct and make sense, but when I run it HOPING it to be that user account, the error is saying that this service account does not have permissions needed in this environment. Which makes total sense! but! I can't figure out how to stop terraform from running as this service account and not as my own active user account.
Error: Error loading state: Failed to open state file at
gs://dxxxxdefault.tfstate: googleapi: got HTTP response code 403 with
body: AccessDeniedAccess
denied.terraform-win#xxxx.iam.gserviceaccount.com
does not have storage.objects.get access to the Google Cloud Storage
object.
The error message said that your service account terraform-win#xxxx.iam.gserviceaccount.com cannot access terraform state on Google Cloud Storage, you just need to add storage.objects.get permission to the service account to fix the error.
If you don't want Terraform to use this service account, you can remove impersonation settings in Terraform and environment variable GOOGLE_APPLICATION_CREDENTIALS.
while creating backend in gcp using terraform getting below errors.
Error loading state: Failed to open state file at gs://tf-state-demo/demo-terraform.state/default.tfstate: googleapi: got HTTP response code 403 with body: AccessDeniedAccess denied.service account does not have storage.objects.get access to the Google Cloud Storage object.
i have given full storage admin role to service account used for creating bucket.
It's an issue with your environment configuration. Terraform use the application default credentials (ADC), therefore you need to create the environment variable GOOGLE_APPLICATION_CREDENTIALS equal to the absolute path of your service account key file.
If you want to avoid to use service account key file (and you have right, because of security reasons), you can use your own credential by doing gcloud auth application-default login
Note: the environment variable has the highest precedence on any other ADC modes
This is a bit of a newbie question, but I've just gotten started with GCP provisioning using Terraform / Terragrunt, and I find the workflow with obtaining GCP credentials quite confusing. I've come from using AWS exclusively, where obtaining credentials, and configuring them in the AWS CLI was quite straightforward.
Basically, the Google Cloud Provider documentation states that you should define a provider block like so:
provider "google" {
credentials = "${file("account.json")}"
project = "my-project-id"
region = "us-central1"
zone = "us-central1-c"
}
This credentials field shows I (apparently) must generate a service account, and keep a JSON somewhere on my filesystem.
However, if I run the command gcloud auth application-default login, this generates a token located at ~/.config/gcloud/application_default_credentials.json; alternatively I can also use gcloud auth login <my-username>. From there I can access the Google API (which is what Terraform is doing under the hood as well) from the command line using a gcloud command.
So why does the Terraform provider require a JSON file of a service account? Why can't it just use the credentials that the gcloud CLI tool is already using?
By the way, if I configure Terraform to point to the application_default_credentials.json file, I get the following errors:
Initializing modules...
Initializing the backend...
Error: Failed to get existing workspaces: querying Cloud Storage
failed: Get
https://www.googleapis.com/storage/v1/b/terraform-state-bucket/o?alt=json&delimiter=%2F&pageToken=&prefix=projects%2Fsomeproject%2F&prettyPrint=false&projection=full&versions=false:
private key should be a PEM or plain PKCS1 or PKCS8; parse error:
asn1: syntax error: sequence truncated
if I configure Terraform to point to the application_default_credentials.json file, I get the following errors:
The credentials field in provider config expects a path to service account key file, not user account credentials file. If you want to authenticate with your user account try omitting credentials and then running gcloud auth application-default login; if Terraform doesn't find your credentials file you can set the GOOGLE_APPLICATION_CREDENTIALS environment variabe to point to ~/.config/gcloud/application_default_credentials.json.
Read here for more on the topic of service accounts vs user accounts. For what it's worth, Terraform docs explicitly advice against using application-default login:
This approach isn't recommended- some APIs are not compatible with credentials obtained through gcloud
Similarly GCP docs state the following:
Important: For almost all cases, whether you are developing locally or in a production application, you should use service accounts, rather than user accounts or API keys.
Change the credentials to point directly to the file location. Everything else looks good.
Example: credentials = "/home/scott/gcp/FILE_NAME"
Still it is not recommended to use gcloud auth application-default login, Best best approaches are
https://www.terraform.io/docs/providers/google/guides/provider_reference.html#credentials-1
I am trying to apply the role binding below to grant the Storage Admin Role to a GCP roleset in Vault.
resource "//cloudresourcemanager.googleapis.com/projects/{project_id_number}" {
roles = [
"roles/storage.admin"
]
}
I want to grant access to the project level, not a specific bucket so that the GCP roleset can access and read/write to the Google Container Registry.
When I try to create this roleset in Vault, I get this error:
Error writing data to gcp/roleset/my-roleset: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/gcp/roleset/my-roleset
Code: 400. Errors:
* unable to set policy: googleapi: Error 403: The caller does not have permission
My Vault cluster is running in a GKE cluster which has OAuth Scopes for all Cloud APIs, I am the project owner, and the service account Vault is using has the following permissions:
Cloud KMS CryptoKey Encrypter/Decrypter
Service Account Actor
Service Account Admin
Service Account Key Admin
Service Account Token Creator
Logs Writer
Storage Admin
Storage Object Admin
I have tried giving the service account both Editor and Owner roles, and I still get the same error.
Firstly, am I using the correct resource to create a roleset for the Storage Admin Role at the project level?
Secondly, if so, what could be causing this permission error?
I had previously recreated the cluster and skipped this step:
vault write gcp/config credentials=#credentials.json
Adding the key file fixed this.
There is also a chance that following the steps to create a custom role here and adding that custom role played a part.
I get the following error while setting up Firebase as an AWS IAM Identity Provider using OpenID Connect.
We encountered the following errors while processing your request:
Please check .well-known/openid-configuration of provider:
https://securetoken.google.com/<Project ID> is valid.
The AWS IAM Identity Provider setup requires two input parameters, to which I plugged in the following:
Provider URL: https://securetoken.google.com/<Firebase Project ID>
Audience: <Firebase Client ID>
To troubleshoot the error, I opened http://<Provider URL>/.well-known/openid-configuration in a browser and noted the JSON response has the Issuer and jwks_uri fields. I believe these JSON fields indicate the Firebase OpenID Connect Provider URL is valid.
Any idea how I could avoid the above error and successfully set up the AWS IAM Identity Provider?
I contacted AWS support and they helped resolve the problem. Thanks to Shaun H # AWS!
The solution to the problem is to use AWS CLI instead of AWS console to set up an OIDC provider.
I'm pasting relevant parts of Shaun's response below:
1.) Manually obtain and verify the thumbprint using the procedure described here[1].
"ThumbprintList" = "6040DB92306CC8BCEB31CACAC88D107430B16AFF"
2.) Create the OIDC identity provider using the AWS Cli [2].
For example: $ aws iam create-open-id-connect-provider --cli-input-json file://oidc.json Note - the format would be:
aud Audience Must be your Firebase project ID, the unique identifier for your Firebase project, which can be found in the URL of that project's console.
iss Issuer Must be https://securetoken.google.com/<projectId>, where is the same project ID used for aud above.
Content for file://oidc.json: (replace with your Project ID)
{
"Url": "https://securetoken.google.com/<Firebase Client ID>",
"ClientIDList": [ "<Firebase Client ID>" ],
"ThumbprintList": [ "6040DB92306CC8BCEB31CACAC88D107430B16AFF" ]
}
[1] http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
[2] http://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html