6 mins to read
Complete End-to-End Visibility with Vault Hashicorp & Sonrai
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 security. It is important to understand how resources are protected, and how those protections are managed. 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, 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, like HashiCorp Vault, enable 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 HashiCorp Vault to see the whole picture.
Vault Policy Framework
While powerful, HashiCorp Vault’s policy framework is only aware of what is a configuration. By design, Vault can’t see into the resources leveraged in the policy, such as cloud IAM 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 is unaware of the specific resources provision credentials can access or what effective permissions exist 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 may have gaps in visibility, and may not be able to connect the dots across their cloud environments.
The Sonrai platform provides customers with complete end-to-end visibility. Sonrai clearly shows who or what can access HashiCorp Vault secrets, who or what can access cloud resources through Vault secrets engines, and what effective permissions are granted to these resources.
Let’s dive into a couple of examples together …
Access HashiCorp Vault Key & Value Secrets
As above, a common use case for HashiCorp Vault is to protect secrets such as tokens and encryption keys. These secrets are in Vault’s Key/Value (KV) secrets engine under a specific path. The path gives permission to read the secrets to identities such as AWS IAM principals and more. Use Vault auth methods to 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"]
}Example Breakdown
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 further into the Sonrai interface, we can see exactly how these resources gain 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 assumes the AllsafeVaultRole role in AWS. HashiCorp Vault configuration includes a policy named aws-secret-policy. This 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 need to identify all of the Vault auth methods assigned to 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 principles – not an easy task.
Answer Key Questions
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.
Using the Sonrai platform, it’s trivial to answer 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?
Access Cloud Resources via HashiCorp Vault Secrets Engines
Another common HashiCorp Vault use case is to securely authenticate identities and provision access across clouds. This can leverages 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 is time-based and is automatically revoked when the Vault lease expires.”
We frequently see customers leverage HashiCorp Vault in between their IAM users and data stores in AWS. This 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. Essentially it’s 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
Example Breakdown
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 further into the Sonrai interface again, we can see exactly how these resources can be accessed for 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 allow 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.
Answering Access Questions
In addition, Sonrai continually tracks audit events from the cloud platforms, so that you can identify when these data resources are 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:
- 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, 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.
Read the latest news and insights
04.22.2020
Missed our webinar? Don’t worry. We breakdown the...
04.14.2020
Understand the benefits and challenges of identity...
