I’m trying to figure out how to handle access to private packages.
For context, I’m using an on-prem builder, but I think this applies to bldr.habitat.sh also.
I have an AWS EC2 instance where I’ve installed my/awesome-package
Originally I did this by copying the .hart file up there and then installing that. The difficulty was at the time the EC2 box couldn’t see my on-prem builder because we don’t have it out on the www.
So I rebuilt the package with my public habiat keys and then uploaded that.
Fast forward I have setup network / firewall rules that allow that EC2 instance access to my on-prem builder, so I can have EC2 install directly from there.
But If I want to make this package private I have to have an access token to put on my EC2 box in order to install / upgrade it.
Where do I put the access token so that the supervisor will be able to install updates when they become available?
It seems like it’s going to be problematic if I have to put my personal access token on several servers. What if I need to change it? Or if one of the servers were to get compromised? I don’t think I can create additional users without creating github accounts too?
As it functions today this has to be provided as an envvar. If you're running habitat on virtual machines the most straightforward way is to have this in your systemd unit file. The envvar is HAB_AUTH_TOKEN. We've got some more info on that in the docs I think there might be more details elsewhere in there.
This is where things get dependent upon the environment you're running in. I think it's likely that we have a feature gap here - I think allowing users to specify this key in the cli.toml is probably a sane feature request. WRT managing and maintaining that, I think that's likely best solved somewhere in the provisioning or infrastructure management layer. That being said that's going to be quite closely to whether you're running in containers or on VMs, and specifically what your image build pipeline/provisioning tools look like.
Unfortunately right now the only thing you could probably do to workaround the way those auth tokens are handled is to create a service account from a different email address, add that to the origin and generate an auth_token for it. At least as far as I can tell. I think the way we’ve got authentication working today isn’t quite correct.