usage of app-id authentication?

[Mark Anderson]

i don't understand the app id authentication use case: i don't understand how it helps much to have two hard-to-guess credentials

(app-id and user-id) versus managing just a single hard-to-guess credential (such as a token).

on a perhaps related note, is the cidr_block option only available with the "app id" authentication backend?

i'm not sure why that would have to be?

-mda

[Armon Dadgar]

Hey Mark,

The reason this is done is to better support configuration management systems. You do not

want to directly commit the singe token to something like Puppet or Chef as it allows any system

with access to extract that token.

However, with the app-id auth backend you can split the app-id from the user-id. You would create

an app-id for the “web” service (a UUID or random string) and commit that to Puppet. The user-id

can be generated any number of ways, using a system MAC, binary checksum, linux kernel UUID, etc.

This second factor is not in a centralized system and requires access to the system itself. 

In this way, access to the config management system or version control repository is not enough

to gain access to Vault.

The “cidr_block” option is currently only available to the “app id” backend, but could be implemented

as an enhancement with any auth backend.

Hope that helps!

Best Regards,

Armon Dadgar

--
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 post to this group, send email to vault...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/e418cf6c-c6a3-4643-990c-7ea3f07afa74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark D. Anderson]

but to play devil's advocate, isn't this to a certain degree just security by obscurity?

because except for the cidr_block, nothing enforces that the user-id actually corresponds to any

information on a given client host. So if someone knows the mechanism for user-id generation, and has access to 

some authorized host A, then they can also generate that same user-id and use it on any other host,

right?

 

-mda

[Armon Dadgar]

Mark,

This is not security by obscurity any more than a username or password. There are multiple

factors that must be known and presumably are only known to the client (just like user/pass).

In fact, because the endpoint is well documented and the code open source, it’s even harder

to argue that its secure through obscurity.

If somebody did a multi-factor compromise of the app-id and user-id and IP spoofing, that

is really not much different than a user/password compromise.

Best Regards,

Armon Dadgar

[Mark D. Anderson]

Oh, i by no means didn't mean to impugn the vault project as a whole -- in fact the design is qualitatively superior

to every commercial alternative that i've looked at recently, for a consulting client.

 

My point was actually the same as what you've said below -- that despite the confusing terminology of

"app id" and "user id", that it is pretty much identical to a user/password pair -- the first of the pair can be public

and kept in a config management/source control, while the second has to be kept secret.

In fact if someone wanted to, they could use the user/password auth backend, and simply adopt the convention

of making the password be some deterministic function of MAC address, kernel id, etc. -- just like

the "user id" of the app-id backend.

 

The two auth backends do differ currently in the cidr_block support, but really that is orthogonal and would be a useful

feature with any auth backend.

 

-mda

[Michael Fischer]

What do you consider best practice to be with respect to the inputs?  Ideally, at least one of them would come from a piece of data that could only be obtained via root privilege on the host. 

MAC addresses are out (these are readily obtainable via ifconfig by an ordinary user).

Hardware serial number: good for bare metal (DMI is only readable by root), but what about VMs/cloud instances?  Is there such a thing?

One could generate an HMAC using a secret key and the MAC address (which is not guaranteed to be globally unique in some cloud providers, BTW) but then you have to find some way to securely share the secret key.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/etPan.5575074c.42c296bd.1159f%40Armons-MacBook-Air-2.local.

[Jeff Mitchell]

"MAC addresses are out (these are readily obtainable via ifconfig by

an ordinary user)." -- This assumes that there is ordinary user
access. Many systems set up by automated processes such as Ansible or
Chef have no access by any users other than administrators. This does
of course not go into a discussion of compromised processes, but for
many users this may be enough.

--Jeff

> https://groups.google.com/d/msgid/vault-tool/CABHxtY5G9FXOO5MMJPt2bO5UteRj9Oj_j%2B9dnu3cGTydAyXwkw%40mail.gmail.com.

[Michael Fischer]

If there is a system reachable by a non-admin on the same subnet, it's easy enough to find out via an ARP request.

$ arp <trusted-machine-ip>

[Jeff Mitchell]

On Mon, Jun 8, 2015 at 3:47 PM, Michael Fischer <mfis...@zendesk.com> wrote:
> If there is a system reachable by a non-admin on the same subnet, it's easy
> enough to find out via an ARP request.
>
> $ arp <trusted-machine-ip>

I'm not sure why there would be in any sort of a scenario where you
have fully automated machines. But regardless, use disk IDs or some
other piece of non-network-related info.

app-id doesn't require you to use MACs. If you really want to ensure a
user must have root on the local system, be creative. Write a value
onto the disk into the space between the MBR and the first partition,
which these days is usually quite far off and can store a ton of info.
Ordinary users don't have read access to /dev/sdX.

--Jeff

[Michael Fischer]

On Mon, Jun 8, 2015 at 12:51 PM, Jeff Mitchell <jeffrey....@gmail.com> wrote:

app-id doesn't require you to use MACs. If you really want to ensure a
user must have root on the local system, be creative. Write a value
onto the disk into the space between the MBR and the first partition,
which these days is usually quite far off and can store a ton of info.
Ordinary users don't have read access to /dev/sdX.

Maybe we can come up with something a little less baroque and more cloud-friendly...

Thanks,

--MIchael

[Jeff Mitchell]

If the point of app-ID is something unique to a specific box, you
can't do much better than writing a specific identifier onto that
box's actual hardware.

Honestly, I don't understand what your concern is. App ID is an idea
of two different secrets rather than a single token. The what and how
is really up to you. What is (for reasons I don't understand) baroque
and "cloud-unfriendly" (whatever that means) to you is relatively
secure to me, but our needs and security concerns may not be the same.

--Jeff

[Michael Fischer]

Let's see what ideas others have about what might make for good, relatively secure, and easy to obtain inputs.  People are free to use MAC addresses if they want, but to me, the best input values are ones that can't be easily obtained by merely taking values from a pair of relatively open sources that are open to more than just administrators (source code repos and some trivially collectible hardware attribute).

Your idea about scribbling keys onto the disk isn't terrible, but I think it's too challenging to implement in practice if there are other better sources of data out there.  Plus it would have to be an out-of-band process that could get in the way when you want to do things like auto-scale.   Unless, of course, you've actually implemented such a thing, in which case, please point us to your sources!

Thanks,

--Michael

--
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 post to this group, send email to vault...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAOx6V3YzhchxFRSS0nTjzDPnvwCpxcRkjaueQp3vo%2BOCE9gzBA%40mail.gmail.com.

[Clay Bowen]

When using this method, I used a hash of the MAC address and a the server's public key file (concatenated together) with a specific hash seed.  This provides a pretty good system-based user-id.  Not perfect, but better than MAC alone.

Thanks,

Clay

[Mark D. Anderson]

Actually, my conception of app-id is that it is essentially identical to user-password.

It isn't "two different secrets", because the first of the pair goes into config management/source control

and in general is not going to be kept very secret.

 

The only difference between app-id and user-password, is that in the app-id case, the second

of the pair (confusingly called "user id" instead of simply "password") is never stored 

anywhere in one place, but is simply a function of privileged sources (kind of like "what you have"

versus "what you know").

 

This is useful for a batch program that needs to wake up and do something without human intervention,

and is an approach to solving the bootstrapping problem of how it can authenticate itself to the vault

without making the authentication credentials easy to find.

 

But that really could be implemented with the user-password auth backend -- just apply that algorithm

once (reading disk ids or whatever), and store the resulting password into the vault, for use with that "app id".

 

-mda

[Jeff Mitchell]

I've not done it, but I think it would be easy to do in Ansible. Loop
over a set of machines, passing in the app ID; on the machine just
have Ansible run "dd" with appropriate offsets for the data; also pass
that into Vault in a curl call. Reverse the "dd" process to read it
back.

You can either store the values in Ansible Vault, or simply create an
ephemeral file with the values that you delete after it's all set.

There are certainly going to be other sources of data out there, but I
don't think it's good practice to dismiss values that meet your
criteria out-of-hand as "baroque" and "cloud-unfriendly". Half the
point of app-ID is to have values that are *not* in the cloud :-)

--Jeff

[Jeff Mitchell]

On Mon, Jun 8, 2015 at 4:17 PM, Mark D. Anderson <m...@discerning.com> wrote:
> Actually, my conception of app-id is that it is essentially identical to
> user-password.
> It isn't "two different secrets", because the first of the pair goes into
> config management/source control
> and in general is not going to be kept very secret.

That depends. Using something like Ansible Vault, you can keep that
information encrypted up until actual deployment time, with a password
known only to a few. It's not quite the same as, say, a public part of
an RSA key.

> This is useful for a batch program that needs to wake up and do something
> without human intervention,
> and is an approach to solving the bootstrapping problem of how it can
> authenticate itself to the vault
> without making the authentication credentials easy to find.
>
> But that really could be implemented with the user-password auth backend --
> just apply that algorithm
> once (reading disk ids or whatever), and store the resulting password into
> the vault, for use with that "app id".

I do agree that there is really very little practical difference
between app-ID and username/password. It's two parts of a whole either
way. The backends really could be merged without losing much so far as
I can tell.

--Jeff

[Rusty Ross]

First off: Vault is fantastic, and obviously holds amazing future promise as well.

I am thinking through details of using it in production within a few large-scale deployments in AWS, and the potential to mitigate (if not solve) the chicken-or-egg problem for machine authentication of automated resources is great news.

So obviously, I am looking hard at app-id auth, but like some others on this thread, am not yet completely satisfied with an approach to using app-id in cloud deployments.

Ultimately, I need to handle two separate types of automated machine deployments:

* full EC2 instances

* individual Docker containers (both in ECS and on custom Docker hosts)

Seems like the best approach for user-id might differ between the two. Here are some thoughts and questions I have right now. I'd be interested in any comments from the thread at large.

* I agree with Michael Fischer in that the MAC address is potentially easily visible to many parties, even remotely

* Instance-id also could be pretty visible to others in a number of scenarios

* For EC2 instances, I've considered leveraging IAM roles/instance profiles for bootstrapping the user-id. Perhaps the EC2 instance could leverage its instance profile to access a restricted S3 bucket and fetch a user-id value. In this scenario each instance with the same role would probably use the same user-id, which would somewhat limit the granularity of Vault audit logs, but that might be an ok tradeoff

* For Docker containers, I am not sure yet. Do folks have ideas as to a semi-secret derivable user-id in a containerized environment? (I believe the app-id auth docs mention containers as a use case, so I am wondering if Hashicorp has any thoughts and/or examples about best practices with app-id auth in containers.)

* What is the current thinking (if any) about scripting a secure out-of-band process to dynamically create user-id/app-id maps in Vault when EC2 instances and ECS containers are instantiated in, say, an autoscaling event?

Best,

Rusty

[Clay Bowen]

Hey Rusty.  I have a similar use case which is why I decided to use the CERT backend for authentication.  I can then distribute the CERT to the instances that need access to the vault, in a shell-less account (shell set to /usr/bin/nologin) and the scripts that do work in the user's crontab would start by "/usr/bin/bash -c "<script>""  The cert would be set read only by the nologin user, in the .ssh directory under the user's home directory (set to 700), so the chance of it being compromised is pretty low.  Since the secrets that user can access would be controlled by policy, it further ensures a pretty safe method.

Thanks,

Clay

[Jonathan Sokolowski]

I've been working an automated deployment for both instances and docker containers.

I've leveraged autoscaling events and registrator to send SNS notifications to a trusted instance running an app-id registration process.

For autoscaling: I lookup the instance ID and IP, registering that as a user-id and limit the cidr block to <IP address>/32

For registrator/docker events: I use the container ID + host IP in a similar fashion.

This strategy relies on controlling who has the ability to publish to the SNS topics, otherwise an attacked can essentially spoof app-id registrations.

The currently implementation involves running the registration daemon on it's own instance, however I think AWS Lambda could be a really nice fit for this once it's more widely available and can access VPC resources.

I've also got an experimental build of registrator which support SNS as a backend.

Hopefully gives some other people ideas, and would love any feedback too :)