Sonrai Security and HashiCorp Vault

Andrew Stott

January 7, 2020

Complete End-to-End Visibility

Solutions such as HashiCorp Vault enable Security and Cloud teams to work together. As application workloads and critical data migrate to the cloud, it becomes even more important to rethink how these resources are protected, and how those protections are managed.  This is because traditional controls from the legacy on-premise world don’t typically align with the cloud’s low-trust, high-complexity, and ephemeral nature. If your organization is currently leveraging public cloud platforms such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform, you’ll need to understand your options sooner rather than later.  Otherwise, identifying over-privileged identities, responding to incidents, and addressing cloud compliance requirements becomes nearly impossible.  

Solutions such as HashiCorp Vault enable Security and Cloud teams to both protect secrets and securely provision access to these critical cloud resources.  However, getting visibility into specifically who and what can access those secrets and cloud resources is still very difficult, simply because you need more than Vault to see the whole picture.   

HashiCorp Vault’s policy framework, while very powerful, is only aware of what is configured.  By design, Vault can’t see into the resources leveraged in the policy, such as cloud IAM users and roles, IAM permissions, etc.  If you leverage Vault’s AWS auth method to allow an AWS IAM role to read a Vault secret, for example, Vault doesn’t know which IAM users can assume that role.  The same is true when you use Vault’s secrets engines to provision credentials back into the cloud — Vault doesn’t know the specific resources that those provisioned credentials can access or what effective permissions are being granted in the cloud.  This is especially tricky when talking about access paths that involve multiple clouds, such as Azure AD (Active Directory) to AWS via HashiCorp Vault. Therefore, Vault users are typically left with gaps in visibility, and can’t connect the dots across their cloud environments.  

The Sonrai platform provides customers with complete end-to-end visibility, clearly showing who or what can access HashiCorp Vault secrets, who or what can access cloud resources through Vault secrets engines, and what effective permissions are being granted to these resources.  

Let’s dive into a couple examples together…

Accessing HashiCorp Vault Key & Value Secrets

As we mentioned above, a common use case for HashiCorp Vault is to protect secrets such as tokens, passwords, certificates, and encryption keys.  These secrets are stored in Vault’s Key/Value (KV) secrets engine under a specific path. Permission to read the secrets can be granted to identities such as AWS IAM principals, AWS EC2 instances, Azure Managed Service Identity (MSI) resources, Google Cloud IAM service accounts, Google Compute Engine (GCE) instances, and more.  This is accomplished using Vault auth methods which allow Vault to authenticate cloud identities and assign a set of policies to those identities.

The configuration to implement this is very straightforward, and consists of three parts:
1. The auth method (typically AWS, Azure, or Google Cloud)
2. The KV secrets engine 
3. The Vault policy to allow the configured auth method to read the KV secrets

The auth method would identify an IAM principal, and assign a Vault policy – this example uses the AWS auth method:

{ 
         "role": "allsafevault",
         "auth_type": "iam",
         "bound_iam_principal_arn :
         ["arn:aws:iam::000000000000:role/AllsafeVaultRole"],
          "policies": [
                 "aws-secret-policy"
          ],
          "max_ttl": 1800000
}

Here’s the HashiCorp Vault policy that we’re using, although there are certainly other ways to set this up:

path "secret/*" {
    capabilities = ["read", "list"]
}

In this example, we have a credit card secret stored in HashiCorp Vault – using Sonrai’s public cloud security platform, we can easily determine who and what can access it, and what effective permissions those identities have:

Drilling in further into the Sonrai interface, we can see exactly how these resources are being granted these permissions.  AWS IAM permissions example – here is the “read” access path for Elliot, and AWS IAM user:

In this case, Elliot is a member of the Allsafe group, which is allowed to assume the AllsafeVaultRole role in AWS.  HashiCorp Vault is configured with a policy named aws-secret-policy which grants this AWS role with read and list capabilities for the KV secret store.  

Without the Sonrai platform, you would first need to determine which HashiCorp Vault policies grant the read capability to this secret.   Then you would need to identify all of the Vault auth methods that are assigned those policies, and determine which IAM principals are referenced in those auth methods.  Finally, you would need to go back to AWS, and try to determine which identities can assume those IAM principals – not an easy task.

Sonrai Security continually updates these models inside our platform, too, so you always have the most current data around identities, effective permissions, and access paths.  In addition, Sonrai tracks HashiCorp Vault audit logs, so that you can identify when secrets are being accessed and by whom – this allows for easy identification and remediation of over-privileged identities.  The Sonrai platform can also monitor for and alert on changes to the “can access” and “did access” models, so that you can detect and respond to changes immediately.  

As you can see, using the Sonrai platform, it’s trivial to answer a number of key questions around access to this sensitive Vault secret:

  • Who and what can access this secret?
  • Who and what has accessed this secret?
  • What has changed with respect to the above? 

Accessing Cloud Resources via HashiCorp Vault Secrets Engines

Another common HashiCorp Vault use case is to securely authenticate identities and provision access across clouds.  This is accomplished by leveraging Vault secrets engines, which allow Vault to connect back into public clouds like AWS, Azure, and Google Cloud.  For those not familiar with the benefits of such an architecture, I’ll let HashiCorp explain using an AWS example:

“The AWS secrets engine generates AWS access credentials dynamically based on IAM policies. This generally makes working with AWS IAM easier, since it does not involve clicking in the web UI. Additionally, the process is codified and mapped to internal auth methods (such as LDAP). The AWS IAM credentials are time-based and are automatically revoked when the Vault lease expires.”

We frequently see customers leverage HashiCorp Vault in between their IAM users and data stores in AWS, which allows them to provision individual users with access to a role in the cloud.  The configuration in Vault is a little more complex than for the KV secret store example from above, but essentially it’s broken into three components:  

1. The auth method (typically AWS, Azure, or Google Cloud)
2. The secrets engine (again typically AWS, Azure, or Google Cloud)
3. The Vault policy to allow the configured auth method to read the secrets engine 

In this example for IAM Permissions s3 below, we have an S3 bucket (ecorp-travelrecords) which contains travel record data.  As before, we can easily determine who and what can access this bucket and what effective permissions those identities have, even when that access is provisioned through HashiCorp Vault itself:

We see a number of production AWS IAM roles, and some IAM users, with a variety of access to this S3 bucket.  Drilling in further into the Sonrai interface again, we can see exactly how these resources are being granted these permissions.  Below is the “read” access path for our Elliot user:

The initial portion of this access path is the same as the KV secret example above:

Elliot is able to assume the AllsafeVaultRole role in AWS, which is mapped to the aws-secret-policy in HashiCorp Vault.  The policy grants read permissions to the AWS secrets engine (specifically to the aws/sts/allsafeprod path) which allows Vault to generate credentials for the AllsafeProdRole role.  Following along on the access path, we can see that AllsafeProdRole has permissions in AWS to list all buckets.  

Without the Sonrai platform, figuring out who and what has access to this S3 bucket would be a massive undertaking.  You would first need to determine which AWS IAM roles have access to this bucket, taking into account all of the inline policies, managed policies, resource policies, and SCPs.  Then you would need to pull apart the HashiCorp Vault policies to determine which cloud IAM principals are allowed to provision credentials to those AWS roles. Finally, you would need to go back to AWS, and try to determine which identities can assume those cloud IAM principals – as we mentioned above, not easy.

In addition, Sonrai continually tracks audit events from the cloud platforms, so that you can identify when these data resources are being accessed and by whom – even when this access occurs cross-account, cross-cloud, or through HashiCorp Vault.  Also, just as we discussed above, Sonrai monitors for and alerts on changes to the “can access” and “did access” models, regardless of whether those changes are due to cloud IAM policy changes or Vault policy changes.  

Using Sonrai, you can answer the following questions around access to cloud data resources like S3 buckets, Azure CosmosDB, GCP Bigtable, file stores, and more:

  • Who and what can access this data resource, even through HashiCorp Vault?
  • Who and what has accessed this data resource, even through HashiCorp Vault?
  • What has changed with respect to the above? 

Hopefully by now you’ve seen how the Sonrai platform can provide complete end-to-end visibility in public cloud environments, particularly into the complex relationships between identities (users, roles, compute, serverless functions, etc) and data resources.  Our unique integration with HashiCorp Vault extends this visibility to clearly show who or what can access HashiCorp Vault secrets, who or what can access cloud resources through Vault secrets engines, and what effective permissions are being granted to these resources.

If you’d like to see for yourself how the Sonrai platform can help your organization, please reach out to us to schedule a demo.