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

Feature Request: add provider argument use_child_token to control child token creation #722

Closed
rokrokss opened this issue Apr 9, 2020 · 6 comments · Fixed by #775
Closed

Comments

@rokrokss
Copy link

@rokrokss rokrokss commented Apr 9, 2020

Terraform Version

v0.12.24

Affected Resource(s)

  • vault_token

Expected Behavior

User can choose whether to use child token or use the injected token itself.

Actual Behavior

One cannot use the injected token itself.
Since the usage of child token is default and cannot be refused, vault_token resources created with terraform will be revoked in 20minutes(default of max_lease_ttl_seconds.)
There are periodic service tokens which are meant to have possibility to live no max TTL.

For the developers using terraform to create vault resources, they might not be aware of the child token because the create vault_token resources won't show that their parent has a short TTL. I've been struggling while dealing with periodic tokens disappearing in 20 minutes without a notion.

Steps to Create Periodic Tokens


resource "vault_token_auth_backend_role" "test_role" {
  role_name           = "test_role"
  token_period        = "2592000"
}

resource "vault_token" "periodic_token" {
  role_name = vault_token_auth_backend_role.test_role.role_name
}

References

@rokrokss rokrokss changed the title [Feature Request] add provider argument use_child_token to control child token creation Feature Request: add provider argument use_child_token to control child token creation Apr 21, 2020
@tyrannosaurus-becks
Copy link
Contributor

@tyrannosaurus-becks tyrannosaurus-becks commented May 14, 2020

@rokrokss hi! Let's move our conversation over to here because it has steps to reproduce what you're going for in the linked PR.

So, when I use a Terraform config like this:

provider "vault" {}

resource "vault_token_auth_backend_role" "test_role" {
  role_name           = "test_role"
  token_period        = 60
}

resource "vault_token" "periodic_token" {
  role_name = vault_token_auth_backend_role.test_role.role_name
}

I receive a valid periodic token in Terraform state. If I log in with it and test it and renew it, it's valid.

$ vault login s.n2RJEoxa2KXynnvpX8snuhA4
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                s.n2RJEoxa2KXynnvpX8snuhA4
token_accessor       ujrc5Dzwd3pGA0TT1RuQckfY
token_duration       37s
token_renewable      true
token_policies       ["root"]
identity_policies    []
policies             ["root"]
tbex@pop-os:~/Desktop/tf-testing$ vault token renew s.n2RJEoxa2KXynnvpX8snuhA4
Key                  Value
---                  -----
token                s.n2RJEoxa2KXynnvpX8snuhA4
token_accessor       ujrc5Dzwd3pGA0TT1RuQckfY
token_duration       1m
token_renewable      true
token_policies       ["root"]
identity_policies    []
policies             ["root"]
tbex@pop-os:~/Desktop/tf-testing$ unset VAULT_TOKEN
tbex@pop-os:~/Desktop/tf-testing$ vault token renew s.n2RJEoxa2KXynnvpX8snuhA4
Key                  Value
---                  -----
token                s.n2RJEoxa2KXynnvpX8snuhA4
token_accessor       ujrc5Dzwd3pGA0TT1RuQckfY
token_duration       1m
token_renewable      true
token_policies       ["root"]
identity_policies    []
policies             ["root"]
tbex@pop-os:~/Desktop/tf-testing$ vault token lookup
Key                  Value
---                  -----
accessor             ujrc5Dzwd3pGA0TT1RuQckfY
creation_time        1589474338
creation_ttl         1m
display_name         token-token
entity_id            n/a
expire_time          2020-05-14T09:40:47.003074886-07:00
explicit_max_ttl     0s
id                   s.n2RJEoxa2KXynnvpX8snuhA4
issue_time           2020-05-14T09:38:58.320447106-07:00
last_renewal         2020-05-14T09:39:47.003074982-07:00
last_renewal_time    1589474387
meta                 <nil>
num_uses             0
orphan               false
path                 auth/token/create/test_role
policies             [root]
renewable            true
role                 test_role
ttl                  55s
type                 service

Note that I can renew it indefinitely unless I fail to renew it within the 60 seconds I've configured.

@rokrokss
Copy link
Author

@rokrokss rokrokss commented May 14, 2020

@tyrannosaurus-becks I had the similar setup and mine was gone in 20 minutes. Can you try with some longer periodic token and try renewing after 18 minutes, it gives no error and shows it gets renewed but was gone in 2 minutes.

@rokrokss
Copy link
Author

@rokrokss rokrokss commented May 14, 2020

https://github.com/terraform-providers/terraform-provider-vault/blob/master/vault/provider.go#L726
This will be its parent. Which is gone in default 20 minutes, we can set a longer ttl for that token but not infinite.

@tyrannosaurus-becks
Copy link
Contributor

@tyrannosaurus-becks tyrannosaurus-becks commented May 15, 2020

Ah, I see! Thanks for linking to that. So the child token created there has a default max TTL of 20 minutes, driven by this field.

Hm, I'm reluctant to stop using child tokens or to support periodic ones for the security reasons described here. Basically, tokens can be written out to Terraform state, and thus viewed, logged, or leaked. Having the tokens be limited in life reduces the risk of them being leaked. I'm concerned that if we add support for periodic, never-ending tokens, we're creating a way for folks to shoot themselves in the foot security-wise.

Is your use case achievable by simply extending the max TTL?

@rokrokss
Copy link
Author

@rokrokss rokrokss commented May 18, 2020

Not, really. The created tokens need to have infinite max TTL, but I made it with cli. In my opinion I think we need an open way to bypass obscured child token creation. I think people can expect that tokens might be in tfstates but not the child token problem because it is hard to see with logs.

@tstraley
Copy link
Contributor

@tstraley tstraley commented Dec 7, 2021

#775 was merged - please see PR for details.

When an upcoming release includes that change, you will be able to configure the vault provider to skip creation of the child token for situations like these where you do not want a limited TTL on the token used by Terraform.

provider "vault" {
  skip_child_token = true
}

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