Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate .flyrc into two files - one with targets and one with bearer tokens #5242

Open
ari-becker opened this issue Feb 26, 2020 · 3 comments

Comments

@ari-becker
Copy link

ari-becker commented Feb 26, 2020

What challenge are you facing?

As an individual Concourse admin of a variety of Concourse instances with a variety of teams in each Concourse instance, I would like to keep my .flyrc in version control along with the rest of my dotfiles, for a) backup purposes and b) to have an easier transition when using different workstations.

What would make this better?

Transition from $HOME/.flyrc to using $XDG_CONFIG_HOME/concourse/fly.yaml (listing the targets) and $XDG_RUNTIME_DIR/concourse/fly-tokens.yaml (listing the bearer tokens that are used when logged into specific targets). The $XDG_CONFIG_HOME/concourse/fly.yaml file can then be version-controlled.

This has the additional security benefit of ensuring that the user is effectively logged out of all of their targets when they log out of their machine (as $XDG_RUNTIME_DIR is deleted when the user logs out), and does the groundwork necessary to build a user daemon that could automatically log a user into each of the user's fly targets upon workstation login, and rotate the bearer tokens so that the user stays logged in while they stay logged into their workstation.

Are you interested in implementing this yourself?

Sorry, I don't have the time at this moment.

@aoldershaw
Copy link
Contributor

I can see merit in splitting up the sensitive information from the configuration. With #6017, this sensitive information could extend beyond tokens, so maybe we can use $XDG_RUNTIME_DIR/concourse/fly-sensitive.yaml or something like that.

Rather than using $XDG_CONFIG_DIR directly, we could use os.UserConfigDir so it's portable to other OS's. I'm not sure what equivalents to $XDG_RUNTIME_DIR exist on OS X and Windows, though - any ideas there?

We should still support $HOME/.flyrc for a while to some extent. This might mean falling back to $HOME/.flyrc and/or having some conversion tool (e.g. fly migrate-rc?) to facilitate the transition.

@avanier
Copy link
Contributor

avanier commented Sep 8, 2020

I think this is a more complex issue than meets the eye. By using os.UserConfigDir, there will be a hit to discoverability, and thus debugging.

Properly implementing this would most likely require a few other changes like:

  • Having the ability override the value set by os.UserConfigDir, either in the environment or in .flyrc to avoid leaving users with edge-case configurations stranded
  • Having the ability to query the current configuration to discover the current token storage file

One thing that seems clear to me from reading through golang/go#29960 is that expectations when it comes to storing things beyond ${HOME} are not universal. If this is a path (no pun intended) that we do want to explore... we'll need to give this a bit of UX testing.

To me, this smells of complexity.

If we are to take cues from say kubectl, keeping everything together in .flyrc and enforcing permissions seems like an approach with a better return on investment for similar security benefits.

@ari-becker
Copy link
Author

I can see merit in splitting up the sensitive information from the configuration. With #6017, this sensitive information could extend beyond tokens, so maybe we can use $XDG_RUNTIME_DIR/concourse/fly-sensitive.yaml or something like that.

👍

Rather than using $XDG_CONFIG_DIR directly, we could use os.UserConfigDir so it's portable to other OS's. I'm not sure what equivalents to $XDG_RUNTIME_DIR exist on OS X and Windows, though - any ideas there?

We should still support $HOME/.flyrc for a while to some extent. This might mean falling back to $HOME/.flyrc and/or having some conversion tool (e.g. fly migrate-rc?) to facilitate the transition.

If we are to take cues from say kubectl, keeping everything together in .flyrc and enforcing permissions seems like an approach with a better return on investment for similar security benefits.

It's not just for the security benefits, it's also for putting fly targets configuration under version control, while not putting secrets into version control. In the absence of a clear pattern for achieving this on OS X or Windows, I can understand keeping the $HOME/.flyrc pattern for OS X and Windows, but then again, if you were to poll everybody who keeps their dotfiles version-controlled, I have the feeling that it would very strongly skew to Linux users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants