I’m trying to determine approaches with using Vault and open vpn access server in AWS.
Eventually I’d like open vpn to rotate its certificates and passwords with vault, but I’m starting simpler to get something working.
Is it actually a safe practice to use something like the IAM role to authenticate to the vault to generate certificates and passwords in this case?
My concern is that since humans can have access to the system, and that it is publicly facing, then how easy would it be for an attacker to utilise those permissions automatically just by getting to the instance? I am using IAM roles to authenticate to vault currently, but only for instances that don’t have humans using them, and so far only instances in private subnets.
Are there other things I should consider? I could also get terraform to only handle the rotation of secrets and prevent the instance from having any implicit access by an IAM Role, but that also is more complexity, maybe its not necessary once I understand more.
I’d love to hear any ideas on what people generally do with this!
Well never say never, but if you practice good password rotation and a secure setup I don’t see why you should be worried any more than an other AWS instance getting hacked. There is nothing special that would make vault any more susceptible than any other application, keep the least-privileges granted model in mind when configuring your systems and roles.
As far as rotating certificates and passwords, AFAIK rotating certs just for the sake of rotating them doesn’t buy you anything. Just set them to whatever length you feel comfortable to and rotate them when they’re about to expire. Passwords I would rotate as often as you can stand it.
Just a note on the openVPN+Vault … I don’t think there exists any tools to let you manage a openvpn instance using vault, so password rotation would have to be a manual/script with terraform.
What concerns me though is that a sudo user might be able to make vault requests. But a standard user with ssh permissions should not. Just because someone gets into the instance with ssh, doesn’t mean they should be able to make a vault request like with this Gruntwork example.
Are you using attached IAM roles for authentication?
If so, as with their use for access to AWS resources permissions are granted to the EC2 instance as a whole and not to any particular user (root, etc.) that might be used. Under the hoot AWS is returning authentication details from the metadata service, which uses the source EC2 instance to determine what to return. As it is just a standard unauthenticated HTTPS request it has no way of knowing if the requester is running as the root user or the nobody user (or any other).
If there are things on the server which should not have access to something (either people or different applications) you should not include that permission in the attached IAM role (or for Vault grant access to the restricted item solely via that role).
Within the pure AWS world you could use assumed roles with additional requirements (e.g. MFA). With Vault you’d use a different auth engine or use a different IAM role (that isn’t attached to the instance).
Thanks @stuart-c for those pointers yes I was thinking about attached IAM roles for authentication (but thanks for getting me to consider alternatives)- So if I take on board what your suggesting, perhaps this could be a workflow if we want Open VPN to be able to acquire and rotate certificates with Vault:
Terraform requests new iam credentials from vault with a brief TTL. Terraform is using encrypted remote state in S3.
Terraform starts open vpn, passing through the newly generated IAM secret key as a var to authenticate vault in a user data script. This authenticates to Vault to use a VPN role.
The vault vpn role has permission constrained to allow creating/rotating its certificates using vault as an intermediary. It can also read/rotate a password to set it for the VPN admin user (24 hour ttl perhaps). That admin user can aquire the password from Vault when they need it.
The secret key is being used to authenticate vault agent, which rotates its token automatically, stored on disk with limited permissions, constraining the ability to make vault requests from that single user. I’m also hoping/assuming that an authenticated session with the vault cli is constrained to that user this way, let me know if I’m mistaken.
My questions by doing this would be:
Would getting terraform to create a unique secret key with vault be a good approach for the first authentication step? Or should I be considering other options?
If Open VPN is automatically rotating its certificates, how are longer living user certs generated? is using vault as the intermediary to sign the user certs enough for open vpn? or must open vpn be signing with its own certs, invalidating user certs each time? if that’s true its not as great as I’d hoped, but still usefull since it provides a means to invalidate user certs after a period of time and force them to aquire new ones. I guess I will figure this out as I go.
@aram535 You mentioned rotating certs and passwords doesn’t necessarily buy you anything, but from my admittedly new understanding of Vault that doesn’t appear true to me. Rotating certs and passwords if it can be done for a use case means a leaked cert/pass if observed in a log or compromised in another way is less likely to be useful (with a short ttl). I’m also hoping in time that if I observed someone attempted to use an old pass / cert then I could raise alarms from those events, and audit and learn from it to back track a vulnerability that I had otherwise missed.
@queglay I actually said “have good password rotation”. Certs are a different issue, there is no point in rotating certs just for the “fun of it”. I have seen/heard of people rotating their SSL certs every 7 days. I cannot see how that could help unless you’re not being secure with your certs in the first place.