How to automate AWS access keys for the key rotation to update in GCP Secrets manager? Is there any service for this automation?
We searched around the google for the documentation we couldn't find any results. Please provide any documentation on this
https://cloud.google.com/iam/docs/configuring-workload-identity-federation is probably the right tool for this. It allows you to give AWS permission to perform GCP actions without needing to export a service account.
Related
CosmosDB serverless account doesn’t support automatic-failover? I have checked for documentation and SLA and have not found anywhere on how to configure serverless account failover etc.
Any help would be appreciated!
The answer is NO, have you looked at the serverless documentation.
A serverless account can only run in a single Azure region. It is not
possible to add additional Azure regions to a serverless account after
you create it.
which means you cannot configure by any ways.
I created a Private Link connection between an Azure VM and a CosmosDB MongoDB Account.
In order to clear out the need for token authentication and taking into account the best practices, I assigned a custom role to the Virtual Machine which has permissions to read and write to CosmosDB.
Now I am trying to connect the VM to CosmosDB using Python (pymongo) without any type of authentication on the uri string. Nevertheless, I am having auth errors and I cannot seem to find any relevant example or information regarding this matter.
Is there any way to achieve this? If not, what are my alternatives? Must I use tokens even with a private link?
#Anupam Chand Thank you for your response in the comment section.
Yes, We Can avoid tokens by creating a service principal for your VM and then assign the appropriate RBAC to the service principal. At present .NET , Java and JavaScript SDKs are currently supported. Python SDK not yet available.
I am working with terraform to spin up different resource in azure. Some of those resources have sensitive data that I would like to store securely in aws secret manager.
Is this a doable process in terraform?
What it is confusing me is the following question:
To be able to access aws secret manager and spin up azure resources, should I have both provider declared in my terraform?
thank you very much for any advice and clarification you can offer
To be able to access aws secret manager and spin up azure resources,
should I have both provider declared in my terraform?
Of course, yes. You need to configure Azure provider and AWS provider for each one.
And I agree with Matt, if the resources have sensitive data, you can use the Azure Key Vault. then you can use only one provider and it will spend less time to get them.
I trying to programmatically create an AWS application within Azure AD with SAML identity provider. I have already done everything needed on the AWS side, but am struggling for Azure. I need to create the enterprise application, and then download the Federation Metadata XML file.
I know how to do this through the Azure console, but am trying to automate the process and need to do all of this through code. I have looked into Graph API and terraform, but cannot seem to find the best way to do this, and am looking for suggestions, or if anyone has done this before.
So I found out a pretty decent way to do this using Microsoft Graph API, for anyone interested,
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial
Anyone has suggestions on how to implement automated key rotation for service account credentials used in the cloud function, AppEngine, GKE.
GCP has added this as one of the recommended security policies for cloud-native services. We can find APIs/client libraries to generate a new private key for the existing service account. But we don't really get how to update the newly generated key on the application deployed in AppEngine, cloud function during runtime.
When you are on Google Cloud components, you don't have to use service account key files. It's a bad practice (even if presented as "standard" in too many tutorials, even Google Cloud tutorials!).
A service account key file is a nightmare to manage. It's a file. You can copy it, you can send it by email, you can even commit it in source repository (maybe public repo!!). In addition, you need to keep it secure and to rotate it regularly...
The best way to simplify this, is to not use them and to rely on Google Cloud component identity. Of course, for all external component, like a CI/CD, an on prem app (or on other cloud provider), the service account key file is the best way to be authenticated on Google Cloud
For Cloud Functions, you can use Cloud Functions Identity
For GKE, you can use Workload Identity
For App Engine, you can rely on the App Engine default service account
For you local development, perform a gcloud auth application-default login to create a default credential with your own user account
In each case, you can recover the default credential in your code. (here an example of a simple credential, without client library, only Google OAuth2 lib)
Note: For some operation, App Engine default service account isn't usable (generate an identity token based on metadata servers or changing the scope of the access_token). For this, I recommend you to impersonate service accounts instead of using service account key file