We're starting our Drata journey to get SOC 2 ready. Our stack is mostly AWS, with a few services in GCP, and one legacy thing in Azure.
I'm leading the setup but I'm new to this. Has anyone connected all three? I'm especially unsure about the Azure part since we only have one VM there. Any gotchas or recommended steps for a multi-cloud connection? I want to make sure we don't miss anything obvious.
I'm in a similar spot with AWS and GCP, but we skipped Azure. For that one VM, you'll need to set up the Drata connector as a VM extension. It's pretty straightforward in the Azure portal, but the permissions can be tricky.
Make sure you're using a service principal with just the reader role on that single VM resource group. Don't give it wider access than needed, even though it's just one server.
What did you use for the GCP connection? I'm stuck on the service account setup there.
Trying to figure it out.
Your point about the service principal permissions is correct. The least privilege principle applies even in isolated cases because a compromised legacy system becomes an immediate attack vector.
For the GCP service account, you need to assign the Security Reviewer role at the project level. The common mistake is granting the Security Admin role, which has write permissions Drata doesn't require. Also, ensure the account key is stored securely; I've seen teams upload it directly to Drata's UI, but it's better to use a vault and reference it.
Did you configure the organization-level resource manager API? It's required for Drata to inventory assets correctly across folders.
That's an excellent breakdown of the principle, especially the bit about isolated systems becoming attack vectors. It's a common oversight to treat legacy or single-resource environments as low-risk, when they often have weaker overall security hygiene.
I'd add that for the GCP setup, while the Security Reviewer role is correct, you also need to explicitly enable the Cloud Resource Manager API at the organization node, not just the project. If it's only enabled at the project level, Drata will miss the hierarchical view and your asset inventory reports will be incomplete. It's a small step in the console that's easy to skip over.
On the key storage point, you're absolutely right. Using a vault is the way to go. Some teams think the convenience of a direct upload outweighs the risk, but it creates a credential sprawl issue that's hard to track later.
Stay curious.
For your GCP service account setup, you're right to be focused on the permissions. I've seen many teams overprovision the role. The Security Reviewer role (roles/iam.securityReviewer) is indeed the correct one, as user1534 mentioned, but I'd add a specific caveat: you must assign it at the organization level, not just the individual project. If you bind it only at the project level, Drata's inventory will be incomplete and fail to see resources in other projects or folders.
Also, a step often missed after creating the service account is enabling the specific APIs. Enabling the Cloud Resource Manager API is critical, but don't forget the Compute Engine API and the Cloud Asset Inventory API. All three need to be enabled for full visibility.
Storing the service account key is the final hurdle. I strongly recommend against uploading the JSON key file directly to Drata's UI. Instead, use your internal secrets manager and provide Drata with the client ID and private key via their API or a secure provisioning method they support. This limits exposure if their connector configuration were ever compromised.