internalURL and adminURL of endpoints should not be visible to ordinary user

[Chaoyi Huang]

if an ordinary user sent a get-token request to KeyStone, internalURL and adminURL of endpoints will also be returned. It'll expose the internal high privilege access address to the ordinary user, and leads to the risk for malicious user to attack or hijack the system.

the request to get token for ordinary user:
curl -d '{"auth":{"passwordCredentials":{"username": "huawei", "password": "2014"},"tenantName":"huawei"}}' -H "Content-type: application/json" http://localhost:5000/v2.0/tokens

the response:
{"access": {"token": {"issued_at": "2014-11-27T02:30:59.218772", "expires": "2014-11-27T03:30:59Z", "id": "b8684d2b68ab49d5988da9197f38a878", "tenant": {"description": "normal Tenant", "enabled": true, "id": "7ed3351cd58349659f0bfae002f76a77", "name": "huawei"}, "audit_ids": ["Ejn3BtaBTWSNtlj7beE9bQ"]}, "serviceCatalog": [{"endpoints": [{"adminURL": "http://10.67.148.27:8774/v2/7ed3351cd58349659f0bfae002f76a77", "region": "regionOne", "internalURL": "http://10.67.148.27:8774/v2/7ed3351cd58349659f0bfae002f76a77", "id": "170a3ae617a1462c81bffcbc658b7746", "publicURL": "http://10.67.148.27:8774/v2/7ed3351cd58349659f0bfae002f76a77"}], "endpoints_links": [], "type": "compute", "name": "nova"}, {"endpoints": [{"adminURL": "http://10.67.148.27:9696", "region": "regionOne", "internalURL": "http://10.67.148.27:9696", "id": "7c0f28aa4710438bbd84fd25dbe4daa6", "publicURL": "http://10.67.148.27:9696"}], "endpoints_links": [], "type": "network", "name": "neutron"}, {"endpoints": [{"adminURL": "http://10.67.148.27:9292", "region": "regionOne", "internalURL": "http://10.67.148.27:9292", "id": "576f41fc8ef14b4f90e516bb45897491", "publicURL": "http://10.67.148.27:9292"}], "endpoints_links": [], "type": "image", "name": "glance"}, {"endpoints": [{"adminURL": "http://10.67.148.27:8777", "region": "regionOne", "internalURL": "http://10.67.148.27:8777", "id": "77d464e146f242aca3c50e10b6cfdaa0", "publicURL": "http://10.67.148.27:8777"}], "endpoints_links": [], "type": "metering", "name": "ceilometer"}, {"endpoints": [{"adminURL": "http://10.67.148.27:6385", "region": "regionOne", "internalURL": "http://10.67.148.27:6385", "id": "1b8177826e0c426fa73e5519c8386589", "publicURL": "http://10.67.148.27:6385"}], "endpoints_links": [], "type": "baremetal", "name": "ironic"}, {"endpoints": [{"adminURL": "http://10.67.148.27:35357/v2.0", "region": "regionOne", "internalURL": "http://10.67.148.27:5000/v2.0", "id": "435ae249fd2a427089cb4bf2e6c0b8e9", "publicURL": "http://10.67.148.27:5000/v2.0"}], "endpoints_links": [], "type": "identity", "name": "keystone"}], "user": {"username": "huawei", "roles_links": [], "id": "a88a40a635334e5da2ac3523d9780ed3", "roles": [{"name": "_member_"}], "name": "huawei"}, "metadata": {"is_admin": 0, "roles": ["73b0a1ac6b0c48cb90205c53f2b9e48d"]}}}

[Dolph Mathews (dolph)]

This is by design (but design can always be changed).

First, internal endpoints are intended to be non-"admin" APIs -- basically just the public endpoint on a faster/better/cheaper network (however the deployment sees fit to use it). Exposing internal endpoints to "ordinary" users *should* never be a security risk, and if they are reachable, ordinary users should prefer them over "public" endpoints (although very few clients seems to implement this behavior beyond perhaps glance and swift).

Second, if "admin" endpoints should be somehow hidden from certain users, there's no automagic way for keystone to know (today) if the authenticating user has any specific authorization on the "admin" endpoint, because it's up to that "admin" endpoint to enforce it's own authorization and policy enforcement. But if you really want to go this route, Keystone supports "endpoint filtering" [1] which you could use to manually setup filtering per endpoint, per tenant, etc. So, it's supported, it's not the conventional deployment today.

If endpoint filtering doesn't address your concern, then we should definitely continue the discussion in public.

+1 for making this public (and perhaps marking this Invalid?)

[1] https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-ep-filter-ext.rst

[Tristan Cacqueray (tristan-cacqueray)]

@Dolph indeed, knowledge of internalURL and adminURL does not constitute a vulnerability. Thus it does not need an OSSA task and can be make public for further discussion.

[Chaoyi Huang (joehuang)]

Ok, move to mail-list public discussion.

[Morgan Fainberg (mdrnstm)]

Based on the ML topic, and that admin/internal URL is not universal (nor clearly isolated) this is not something that we can likely fix without breaking the API contract. We could look at changing the format of the catalog, but I think this is a much, much, bigger topic. Many actions need access to the different interfaces to succeed.

Second, if someone does not have the endpoint in the catalog it doesn't prevent them from accessing/using the endpoint if they know if apriori. This is not something that I expect we will change. This should be handled in policy enforcement (currently policy.son)

Longer term we are looking at providing endpoint binding - in theory we could expand this to cover the differing interfaces *where* possible. Feel free to comment at https://review.openstack.org/#/c/123726/ on the token constraint specification which will include the ability to restrict the user from accessing a specific endpoint if they are not authorized to do-so.