Vault SSH Secret Backend

[dbt...@gmail.com]

Hi,

I've been trying to utilize the Vault SSH Secret Backend, and was looking for some opinions on how I could improve my SSH Roles.

I currently have the following:

$ vault read ssh/rails_app/roles/stage

Key               Value

---               -----

allowed_users     *

cidr_list         0.0.0.0/0

default_user     ec2-user

exclude_cidr_list

key_type         otp

port             22

$ vault policies developer

path "ssh/rails_app/creds/*" {

  capabilities = ["write"]

}

$ vault read auth/userpass/users/john

Key     Value

---     -----

max_ttl 0

policies developer

ttl     0

$ vault read auth/userpass/users/mary

Key      Value

---      -----

max_ttl  0

policies developer

ttl      0

On the rails_app server, the config.hcl looks like:

# cat /etc/vault-ssh-helper.d/config.hcl

vault_addr = "https://vault.company.com"

ssh_mount_point = "ssh/rails_app"

ca_cert = "/etc/vault-ssh-helper.d/ca.cer"

tls_skip_verify=false

allowed_roles="stage"

And the user list looks like:

# cat /etc/passwd

...

john:x:502:502::/home/john:/bin/bash

mary:x:503:503::/home/mary:/bin/bash

In this scenario, Vault users john and mary are allowed to request OTP credentials to any IP address. The OTP will only work with the rails_app server, which is verifying using ssh_mount_point "ssh/rails_app" and verifying the allowed role "stage".

However, I can't figure out how to limit which username the OTP is valid for. In this scenario, if john generates an OTP for rails_app, both of the following commands would be valid:

$ vault token-lookup

Key             Value

---             -----

accessor                aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

creation_time   0

creation_ttl     86400

display_name     userpass-john

explicit_max_ttl 0

id               aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

meta             map[username:john]

num_uses         0

orphan           true

path             auth/userpass/login/john

policies         [default developer]

renewable       true

ttl             0

vault ssh -mount-point ssh/rails_app -role stage -strict-host-key-checking=no jo...@1.2.3.4
vault ssh -mount-point ssh/rails_app -role stage -strict-host-key-checking=no ma...@1.2.3.4

What is the recommended way of allowing john to SSH into the rails_app as only john, and not as other users (such as mary)?

Thanks,

Dan

[Vishal Nayak]

Hi Dan,

In the scenario you explained `john` logs in as `john`. The `vault
ssh` command creates a fresh OTP for each invocation, and the OTP is
verified to match the appropriate username by the `vault-ssh-helper`.

Regards,
Vishal

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/1bfc2a18-a307-494c-b8b2-e7e3c3fdee39%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
vn

[dc...@betterment.com]

Hi Vishal,

To my best understanding, because "ssh/rails_app/roles/stage" is validating for "allowed_users *", john would be able to request an OTP which would be valid for logging in as john or mary. Unix users john and mary both exist on the target server. john would be able to use the OTP he generated to log in as either john or mary, since both of those users are valid Unix users, and both names are valid with the "ssh/rails_app/roles/stage" and "allowed_users *". I wouldn't want john to be able to create an OTP and then log in to the target server as a different Unix user.

The only potential solution I could think of was to set up something like the following:

# ---

$ vault read ssh/rails_app/stage/roles/john

Key               Value

---               -----

allowed_users     john

cidr_list         0.0.0.0/0

default_user      john

exclude_cidr_list

key_type          otp

port              22

$ vault read ssh/rails_app/stage/roles/mary

Key               Value

---               -----

allowed_users     mary

cidr_list         0.0.0.0/0

default_user      mary

exclude_cidr_list

key_type          otp

port              22

# ---

$ vault policies john

path "ssh/rails_app/stage/creds/john" {

  capabilities = ["write"]

}

path "ssh/rails_app/prod/creds/john" {

  capabilities = ["deny"]

}

$ vault policies mary

path "ssh/rails_app/stage/creds/mary" {

  capabilities = ["write"]

}

path "ssh/rails_app/prod/creds/mary" {

  capabilities = ["write"]

}

# ---

$ vault read auth/userpass/users/john

Key       Value

---       -----

max_ttl   0

policies  developer, john

ttl       0

$ vault read auth/userpass/users/mary

Key       Value

---       -----

max_ttl   0

policies  developer, mary

ttl       0

# --- rails_app/stage

$ cat /etc/vault-ssh-helper.d/config.hcl

vault_addr = "https://vault.company.com"

ssh_mount_point = "ssh/rails_app/stage"

ca_cert = "/etc/vault-ssh-helper.d/ca.cer"

tls_skip_verify=false

allowed_roles="john,mary"

# --- rails_app/prod

$ cat /etc/vault-ssh-helper.d/config.hcl

vault_addr = "https://vault.company.com"

ssh_mount_point = "ssh/rails_app/prod"

ca_cert = "/etc/vault-ssh-helper.d/ca.cer"

tls_skip_verify=false

allowed_roles="john,mary"

Under the updated scenario, john would have access to get OTP credentials for rails_app/stage, but not rails_app/prod. mary would have access to get OTP credentials for both rails_app/stage, and rails_app/prod. Both policies ensure that each user would only be allowed to log in as the specified user. So, if john requested an OTP credential for rails_app/stage, he would only be able to log in to the rails_app/stage server as john, and not mary.

However, this solution would mean creating a new role for each user that I have. Maybe I'm missing a possibly better solution for what I'm trying to accomplish? Or maybe misunderstanding one of vault_ssh_helper's features? Either way, I appreciate the response, and hopefully you can help me confirm my theories.

Thanks,

Dan

[Vishal Nayak]

Hi Dan,

The `allowed_users` on the role endpoint is used to decide whether or
not to issue a credential against a set of usernames. By specifying a
`*`, a credential will be issued against any username. This does not
mean that the credential issued against a specific username can be
used to impersonate another user (If this is happening to you, please
report back).

The verify endpoint in Vault will take in an OTP and return an
associate tuple `{username, ip, role-name}` to the vault-ssh-helper.
The helper will compare the username that is being logged in, with the
one received by the Vault server before authenticating the session.

There is no need to create separate role entries one for each user.

Also, there is no need for the below ACL rule in the policy, since
Vault works with a "default deny" principle.

path "ssh/rails_app/prod/creds/john" {
capabilities = ["deny"]
}

Hope this helps!

Regards,
Vishal

> https://groups.google.com/d/msgid/vault-tool/b8aa6327-471d-4c3a-852b-cb85c9498263%40googlegroups.com.

[dc...@betterment.com]

Hi Vishal,

"default deny" makes sense. I can definitely remove that ACL rule you provided.

My interpretation of impersonate might be used in a different context. By using "*", I expect to be able to generate a credential against any username. In the Vault logs, I can see that when the OTP is used, it can be linked back to the user who generated that OTP. So, in my particular example of impersonation, I'm not concerned about a Vault user impersonating another Vault user, but for a Vault user to be impersonating a different Unix username. Even if the OTP credential is linked back to the Vault user who generated it, it does not prevent me from stopping an OTP to be used to login as any Unix username. 

It's also possible that my want of locking down each Vault user to a specific Unix username is out of scope. By definition of "allowed_users *" on the role endpoint, any Vault user with access to that role would be able to generate a credential for any username. If I was able to use a definition of something like "allowed_users %vault_username%", that might help, but I don't think ACL provides variable interpolation.

If I wanted to allow Vault user "john" to only generate credentials for Unix users named "john", and for Vault user "mary" to only generate credentials for Unix users named "mary", would that require two separate role entries?

Thanks again,

Dan

[Vishal Nayak]

Hi Dan,

> If I wanted to allow Vault user "john" to only generate credentials for Unix users named "john", and for Vault user "mary" to only generate credentials for Unix users named "mary", would that require two separate role entries?

In this case, yes, having separate role entries make sense.

> It's also possible that my want of locking down each Vault user to a specific Unix username is out of scope. By definition of "allowed_users *" on the role endpoint, any Vault user with access to that role would be able to generate a credential for any username. If I was able to use a definition of something like "allowed_users %vault_username%", that might help, but I don't think ACL provides variable interpolation.

Yes. Vault currently does not provide such a feature.

If maintaining too many role entries is a pain, then it is possible
that a dedicated trusted service, on behalf of users (not users
themselves), create and issue the OTPs. This service can do the
username checks as you might wish.

Regards,
Vishal

> https://groups.google.com/d/msgid/vault-tool/a7a6a652-89d4-4c1e-975d-d01ed2763b4b%40googlegroups.com.

[dc...@betterment.com]

Okay, I think I should have enough information to move forward with a potential solution.

Thanks for the quick responses! (also, thanks for continuing to make awesome products.)

Best,

Dan