I recently needed to authenticate to a service which required that I not only have a secret, but also that I come from a certain host. This became a real problem for me because I wasn’t sure where I was from, or where I would be. In fact, I could be in multiple places at any one time, and I didn’t want to be quarantined in a single location.
In more concrete terms I was authenticating using a Kerberos host principal to the service that required that my host principal be the same host where the request came from. In other words when the service received my request it would do a reverse DNS lookup on my host principal to verify that the request came from that host.
Kerberos usually doesn’t mind where you make requests from. If you have the secret in the form of a username and password, or keytab then the service usually lets you in. However in certain low trust, and high stakes environments the extra layer of security afforded by a reverse DNS lookup is warranted.
This was a problem for me because I was running my application in the cloud where I would have multiple processes doing the request on multiple servers with different IP Addresses. Furthermore none of those servers had a public IP address but instead were hiding behind a router which was using Network Address Translation (NAT).
Luckily for me, all the applications running on the servers behind this router were owned by my team. That is not always the case in cloud environments, where users can share resources including servers with other teams, and sometimes other companies. Therefore I was able to add a DNS PTR record from the router’s IP address, allowing reverse DNS lookups of that IP to resolve to my Kerbos host principal. Now when the secure service did reverse DNS lookup on my request it was satisfied that the request came from a trusted machine (or router in this case).
You might not always be so lucky to have a private network which only you can deploy applications to. In that case you might find that your private network allows you to map a public IP Address to a single node on the private network. You could then reroute outgoing, or egress traffic, from your application through that node in the network. As long as only you can deploy applications with that configuration you could avoid allowing all machines in that network access to the secure service.
Secure Software Engineering 