bound_cidrs on x-forwarded-for header ?
829 views
Skip to first unread message
François Prud'homme
Jul 26, 2018, 4:04:54 AM7/26/18
to Vault
Hello,
I have try to create a very simple role :
vault write auth/token/roles/test -<<"EOH"
{
"allowed_policies": [
"test"
],
"name": "test",
"orphan": true,
"renewable": true,
"bound_cidrs": [
]
}
EOH
But as i'm behind a proxy, permission is always denied :
{
"time": "2018-07-26T08:01:45.264052253Z",
"type": "request",
"auth": {
"client_token": "",
"accessor": "",
"display_name": "",
"policies": null,
"metadata": null,
"entity_id": ""
},
"request": {
"id": "ddbd2c5a-f260-7ed3-e449-4a5397c9471d",
"operation": "read",
"client_token": "hmac-sha256:720e5540b344df875f91ef955116be13bf6b0d346846bb6374507a183e4e5a3f",
"client_token_accessor": "f049bd23-e147-e7cd-09e9-9f926c060618",
"path": "auth/token/lookup-self",
"data": null,
"policy_override": false,
"remote_address": "127.0.0.1",
"wrap_ttl": 0,
"headers": {
"x-forwarded-for": [
"10.2.200.201"
]
}
},
"error": "permission denied"
}
{
"time": "2018-07-26T08:01:45.274688671Z",
"type": "response",
"auth": {
"client_token": "",
"accessor": "",
"display_name": "",
"policies": null,
"metadata": null,
"entity_id": ""
},
"request": {
"id": "ddbd2c5a-f260-7ed3-e449-4a5397c9471d",
"operation": "read",
"client_token": "hmac-sha256:720e5540b344df875f91ef955116be13bf6b0d346846bb6374507a183e4e5a3f",
"client_token_accessor": "f049bd23-e147-e7cd-09e9-9f926c060618",
"path": "auth/token/lookup-self",
"data": null,
"policy_override": false,
"remote_address": "127.0.0.1",
"wrap_ttl": 0,
"headers": {
"x-forwarded-for": [
"10.2.200.201"
]
}
},
"response": {
"data": {
"error": "hmac-sha256:37e2d90a74d68fe4918f7fb9ec41e051242ca8e86b5620d3d69b9a090b5a347a"
}
},
"error": "1 error occurred:\n\n* permission denied"
}
Can we ask to vault to look on "x-forwarded-for" header ?
Chris Hoffman
Jul 26, 2018, 7:05:07 AM7/26/18
to Vault
Do you have X-Forwarded-For set up in your config?
Chris
--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/a44c9380-8004-40db-8cac-4ec8df7ad5ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
François Prud'homme
Jul 26, 2018, 5:52:24 PM7/26/18
to Vault
Ooooops...
Completely miss this point of configuration.
Tests done :
- x_forwarded_for_authorized_addrs = "0.0.0.0"
I could not init cluster... because i'm doing this on server (not behind haproxy)
- x_forwarded_for_reject_not_present = "false"
Resolve last problem :) But... understand that my "0.0.0.0" is not allowing everything, because my 127.0.0.1 source is not allowed :(
- x_forwarded_for_reject_not_authorized = "false"
Resolve last last problem :D
I will continue tests, but it was not "intuitive" to have to put all these options... except if i'm doing something bad... my use case is to get vault accepting every IP... but in some cases, to have the possibility to limit a token on specifics IP.
Many thanks for help :) (but, after going back to docs, i'm not finding this part of configuration very clear when we only try to use "bound_cidrs" tokens)
François Prud'homme
Jul 26, 2018, 6:14:25 PM7/26/18
to Vault
Sorry again... but same problem again :(
$ vault token lookup e1987f41-53e8-8392-5b88-81e8a575c469
Key Value
--- -----
accessor 5550e250-7f03-f136-ccbc-c05090b08777
bound_cidrs [26.0.0.1 30.0.0.0/16]
creation_time 1532642334
creation_ttl 768h
display_name token
entity_id n/a
expire_time 2018-08-27T23:58:54.2826752+02:00
explicit_max_ttl 0s
id e1987f41-53e8-8392-5b88-81e8a575c469
issue_time 2018-07-26T23:58:54.2826752+02:00
meta <nil>
num_uses 0
orphan true
path auth/token/create/test
policies [default test]
renewable true
role test
ttl 767h48m7s
And if i try a token lookup from another place with a good IP :
{
"time": "2018-07-26T22:10:24.7657495Z",
"type": "request",
"auth": {
"client_token": "",
"accessor": "",
"display_name": "",
"policies": null,
"metadata": null,
"entity_id": ""
},
"request": {
"id": "44dfca1e-dd04-f5ae-3c6d-65d201f7e3e2",
"operation": "read",
"client_token": "e1987f41-53e8-8392-5b88-81e8a575c469",
"client_token_accessor": "5550e250-7f03-f136-ccbc-c05090b08777",
"path": "auth/token/lookup-self",
"data": null,
"policy_override": false,
"remote_address": "127.0.0.1",
"wrap_ttl": 0,
"headers": {
"x-forwarded-for": [
"26.0.0.1"
]
}
},
"error": "permission denied"
}
{
"time": "2018-07-26T22:10:24.7657495Z",
"type": "response",
"auth": {
"client_token": "",
"accessor": "",
"display_name": "",
"policies": null,
"metadata": null,
"entity_id": ""
},
"request": {
"id": "44dfca1e-dd04-f5ae-3c6d-65d201f7e3e2",
"operation": "read",
"client_token": "e1987f41-53e8-8392-5b88-81e8a575c469",
"client_token_accessor": "5550e250-7f03-f136-ccbc-c05090b08777",
"path": "auth/token/lookup-self",
"data": null,
"policy_override": false,
"remote_address": "127.0.0.1",
"wrap_ttl": 0,
"headers": {
"x-forwarded-for": [
"26.0.0.1"
]
}
},
"response": {
"data": {
"error": "permission denied"
}
},
"error": "1 error occurred:\n\n* permission denied"
}
(same from 30.0.0.1)
Another thing missing in my configuration ?
Stephen J. Butler
Jul 26, 2018, 7:10:59 PM7/26/18
to vault...@googlegroups.com
On Thu, Jul 26, 2018 at 4:52 PM François Prud'homme <frapru...@gmail.com> wrote:
Ooooops...Completely miss this point of configuration.Tests done :
- x_forwarded_for_authorized_addrs = "0.0.0.0"
I think you want CIDR format here. "0.0.0.0/0", although that seems dangerously insecure.
François Prud'homme
Jul 27, 2018, 4:41:51 AM7/27/18
to Vault
Argh... a mistake again... big thanks for the catch !
It's working :)
From my point of view, for the moment, it's not very insecure :
- Before adding this, without any list of authorized addrs all are accepted
- I earn the possibility of creating ip bounded tokens
- I'm on a private network
As we have audit enable, i may limiting authorized ip addrs in future after compiling all ip captured.
Thx again :)
François Prud'homme
Jul 27, 2018, 10:41:12 AM7/27/18
to Vault
Just for information... i discover a few lines upper https://www.vaultproject.io/docs/configuration/listener/tcp.html#x_forwarded_for_authorized_addrs that vault support the proxy protocol... excellent... i can't tell how i'm happy to see this :)
In conclusion, i have added "send-proxy" to my haproxy backend, and only theses lines to vault conf :
proxy_protocol_behavior = "allow_authorized"
proxy_protocol_authorized_addrs = "127.0.0.1"
(i may modify "allow_authorized" to "deny_unauthorized"... but for unseal case, it's more easier ;))
Reply all
Reply to author
Forward
0 new messages