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

Investigate possibilties for extending vault policies to enable dynamic policices #120

Closed
simonswine opened this issue Mar 7, 2018 · 10 comments

Comments

Projects
None yet
4 participants
@simonswine
Copy link
Member

commented Mar 7, 2018

Currently we can't distinguish between, different instances of the same group #34.

To achieve a separation between different instances we would need to dynamically generate policies that allow AWS instances get certificates for their FQDN.

Investigate our options:

  • Implementing a controller loop that watches Vault's and/or EC2's API and creates the dynamic policies on the fly
  • Is it possible to modify attached policies on an already created token
  • Could this better be solved by a Tarmak Vault plugin, starting of with an fork of https://www.vaultproject.io/docs/auth/aws.html (we would use the EC2 way of authenticating)

To configure a full PKI like we do in tarmak, you can use https://github.com/jetstack/vault-helper/ and its vault-helper devserver subcommand

@simonswine

This comment has been minimized.

Copy link
Member Author

commented Mar 7, 2018

@mt-inside

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2018

Hi!

@simonswine

This comment has been minimized.

Copy link
Member Author

commented Mar 7, 2018

/assign @mt-inside

@jetstack-bot

This comment has been minimized.

Copy link
Collaborator

commented Mar 7, 2018

@simonswine: GitHub didn't allow me to assign the following users: mt-inside.

Note that only jetstack members and repo collaborators can be assigned.

In response to this:

/assign @mt-inside

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@mt-inside

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2018

Hey @JoshVanL, @simonswine , sorry, I commented on the internal issue. Will reproduce here

@mt-inside

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2018

Summary for w/b 5/3/18:

  • I was very new to vault, so installed it, followed the intro guide (static secrets and policies etc)
  • Got an AWS account, added root key, played with STS dynamic secrets
  • Played with terraform vault provider breifly
  • Got source, got vault building, testing and running locally

Blockers:

  • Some time was lost to jetstack vault CSR signing
  • Some time was lost to jetstack AWS sign-in and helpers (doesn't run on a fresh OS install, PR raised)

Next tasks:

  • Run vault on EC2 instance, play with EC2 auth backend
  • Write hello-world auth plugin
  • See under what circumstances policies can be dynamically changed
@mt-inside

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2018

Summary for w/b 12/3/18:

  • Researched dynamic policy:
    • Policy names associated with a token can't be changed
    • Policy contents can
    • Vault Premium uses the Sentinel policy language, which looks like it could so what we want from a static policy (since it's so powerful)
    • There's a github issue asking for dynamic policies (with backreferences like web server routing rules), this was rejected as apparently it would need a lot of code refactoring
  • Researched the AWS EC2 auth engine
    • There's a "role_tag" feature which seems to allow instances to drop some of the privileges their policy mapping would give them

Conclusion:

  • Writing one policy expressive enough to do what we want doesn't seem possible and won't be added
  • Policies can't be added to issued tokens, and EC2 role => policy mappings are static, so we can't add a per-instance policy after it auths, and we can't attach a new one to each instance and work the permissions out afterwards, because role_tag only lets you opt out of policy, not opt in.
  • We could try to write a controller that spots new instances before they try to login. We could add a cloud-init / systemd unit that blocks boot while the policy is made...
  • Easiest method seems to be to write a custom EC2 authenticator, hopefully one that just makes the policy and then proxies through to the real one

Blockers:

  • While researching I tried to get vault running in AWS but wanted it to be repeatable for testing or a possible move to an account where I have root. Hit loads of terraform / cloud-init problems doing this.

Next tasks:

  • Get vault client and server running on AWS, authing to each other.
  • Write hello-world auth plugin

@simonswine simonswine added this to the release-0.4 milestone Mar 21, 2018

@simonswine simonswine assigned kragniz and unassigned mt-inside Mar 21, 2018

@kragniz

This comment has been minimized.

Copy link
Member

commented Mar 22, 2018

I've pulled out the vault awsauth backend and packaged it into a plugin to use as a base. I'm going to be testing it works properly and adding entry points for policy and role creation today.

@kragniz

This comment has been minimized.

Copy link
Member

commented May 22, 2018

@simonswine

This comment has been minimized.

Copy link
Member Author

commented May 22, 2018

Thanks @kragniz for looking into that

@simonswine simonswine closed this May 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.