I have read the docs on this (AWS - Auth Methods | Vault by HashiCorp) but I don’t understand enough about the header_value to feel comfortable in my usage of it. While it does not fail, with my login requests I’ve set it to vault.service.consul everywhere (it works), and it doesn’t really make any sense to me after reading the docs a few times on it. Couldn’t anyone just punch in that string should they try to emulate some request?
I also found that when configuring vault_aws_auth_backend_role in terraform that I had to not provide
…or login via a IAM role auth method would not work.
So what would be considered a secure best practice example of this and why is it used? Is there anyway way of filling in the gaps that might help me grasp beyond what the documentation provides, and the significance / usage of this value?
Let’s say you have two Vault instances, an insecure test instance and a secure production instance. An admin on the insecure instance could listen to authentication requests to that server and then use that information to attempt to login to the secure production instance. By assigning different header values to the two instances, this login will fail. Of course, clients will also need to make sure that they aren’t sending login requests with secure-vault.service.consul login requests to the insecure test server. The important thing is that you choose unique values for each Vault instance and that clients know for each instance. Choosing something like the FQDN clients use to speak to Vault might be one way to guarantee uniqueness and make it easy for clients to know what value to set it to.
So it seems like the header is an unencrypted string to identify an namespace to isolate resources.
The important thing is that you choose unique values for each Vault instance and that clients know for each instance
…so we would make unique variants of these for as many unique vault server clusters we might choose to run is that correct?
Probably being naive here - If I utilised dev.vault.service.consul and someone observed that on a dev instance like you suggested, would it be easy for them to infer, or guess/try variants that they could poke at like prod.vault.service.consul ?
Usually we would probably isolate these in seperate AWS accounts and roles I guess though as well.
Essentially, yes. At a minimum, it needs to be a unique value per security boundary of the Vault infrastructure itself.
Probably being naive here - If I utilised dev.vault.service.consul and someone observed that on a dev instance like you suggested, would it be easy for them to infer, or guess/try variants that they could poke at like prod.vault.service.consul ?
So what? This value needs to be unique, not secret. Just make sure your users aren’t specifying a header value of prod.vault.service.consul when connecting to dev.vault.service.consul.
Ok thanks Joel- by the wording in the docs I got the impression that it was required for security and that it needed to be secret. Now that I see it helps establish a namespace, if we only intend to use one vault cluster, is there any risk or vulnerability in not defining the value at all?
If you really, truly are only ever going to have a single Vault cluster in your org, then it probably isn’t too important to have this header value defined. However, organization plans change and designs change, and you might end up with multiple clusters tomorrow. I would think about defining this header value as a form of “security future-proofing” your setup such that your setup will remain secure even if you end up building multiple clusters in the future.
I respectfully disagree. If it is easy to deduce the value of the header for your PROD Vault cluster, then it does not make any sense to use it.
I would say, you need to generate a decent-strength value and distribute it securely to clients. That way you make it harder for an attacker to establish an existing identity - apparently this header is treated as part of that identity. Here is what I found in the documentation that suggests this approach without explicitly saying it: AWS - Auth Methods - HTTP API | Vault | HashiCorp Developer
Blockquote * iam_server_id_header_value(string: "") - The value to require in the X-Vault-AWS-IAM-Server-ID header as part of GetCallerIdentity requests that are used in the iam auth method. If not set, then no value is required or validated. If set, clients must include an X-Vault-AWS-IAM-Server-ID header in the headers of login requests, and further this header must be among the signed headers validated by AWS. This is to protect against different types of replay attacks, for example a signed request sent to a dev server being resent to a production server. Consider setting this to the Vault server’s DNS name.
Not how at the very end they suggest setting it tot he Vault server’s DNS name. The part that is not publicly known is the private IP address, e.g. ip-12-34-56-78.us-west-2.compute.internal. Of course, this is the private DNS name of the EC2 instance running your Vault server and it is only know internally. External users only see a URL which then Route53 resolves to the DNS of the Load Balancer, NOT the private DNS of your EC2 instances.