ACL support

[xiang90]

We will add ACL soon.

[progrium]

Instead of ACL, how about namespaces?

On Sun, Aug 11, 2013 at 12:30 PM, Xiang Li [email protected] wrote:

We will add ACL control soon.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91
.

Jeff Lindsay
http://progrium.com

[xiang90]

@progrium any more detailed thought?

[progrium]

Let me first ask, what problem will ACL's solve?

[polvi]

Similar to this: http://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#sc_ZooKeeperAccessControl

[progrium]

I see, but what's driving the need in your case?

On Sun, Aug 11, 2013 at 12:56 PM, polvi [email protected] wrote:

Similar to this:
http://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#sc_ZooKeeperAccessControl

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91#issuecomment-22464002
.

Jeff Lindsay
http://progrium.com

[xiang90]

@progrium We replica all the data on cluster machines, which means there is no way to avoid the machines in the cluster get the data. But client outside the cluster can have their own control of the data.

[progrium]

In other words, all data is replicated and public, but some users will want
theirs to be private and/or shareable with trusted parties?

On Sun, Aug 11, 2013 at 12:58 PM, Xiang Li [email protected] wrote:

@progrium https://github.com/progrium We replica all the data on
cluster machines, which means there is no way to avoid the machines in the
cluster get the data. But client outside the cluster can have their own
control of the data.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91#issuecomment-22464027
.

Jeff Lindsay
http://progrium.com

[xiang90]

@progrium When see etcd cluster as a service, the clients need to trust the etcd cluster. Then they can prevent other clients to read/write their data. If they do not trust etcd cluster, then they need to encrypt the data. And the acl will be a way to hide their data structure in the cluster.

[progrium]

My proposal solves this problem but also helps different, uncoordinated applications use the same etcd cluster without worrying about clobbering each other. The basic idea is that along with a common public namespace (or root), there are hidden namespace "roots". There would be a way to provision a namespace root with a unique, unguessable name (uuid?) which serves as an access token for that namespace. When you connect, you can pass this name/token and you will be "chrooted" into a unique namespace.

If you want to share access to this root, you just share the name/token and others can connect. The namespace is just a hidden path in the main structure. Maybe something like:

/.namespaces
    /f3584ec0-02c2-11e3-a03f-f23c91aec05e
    /f3585438-02c2-11e3-a03f-f23c91aec05e

These would not be visible or accessible with regular access. You must explicitly know the namespace you want to connect to.

The big win here is simplicity. ACLs require modeling permissions and users. This maintains the existing simplicity while satisfying most use cases, while also building in a very useful pattern that will be necessary for different third-party applications to use this as a platform.

We were going to add this for our own use in Flynn. Perhaps you guys could take this approach instead of ACLs until there are real, specific needs for more fine-grained ACLs.

[progrium]

Maybe the actual path is a sha256 hexdigest of the uuid namespace name. With salt? Security details.

[xiang90]

@progrium To hide the data under a secret path will be a good way. If the secret path name is sparse and well-hased, there will not be much security problem. Or the attacker can just do random scan based on the algo you generated the secret path. ACL or Hidden path will be determined by how secure the client really want.

[progrium]

You can see how this could be implemented on top of etcd, but I think there
are benefits to it being directly implemented in etcd. It will relieve
users of private data concerns and provide affordance for building third
party applications on top of etcd the right way.

On Sun, Aug 11, 2013 at 1:27 PM, Xiang Li [email protected] wrote:

@progrium https://github.com/progrium To hide the data under a secret
path will be a good way. If the secret path name is sparse and well-hased,
there will not be much security problem. Or the attacker can just do random
scan based on the algo you generated the secret path. ACL or Hidden path
will be determined by how secure the client really want.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91#issuecomment-22464565
.

Jeff Lindsay
http://progrium.com

[xiang90]

@progrium We need to implement that inside etcd. Since we have a list operation, which will leak the hidden path.

[progrium]

Right. There was talk before of a proxy that exposed this functionality and
not provide direct access to the etcd server, but you can still see the
problem with that.

On Sun, Aug 11, 2013 at 1:31 PM, Xiang Li [email protected] wrote:

@progrium https://github.com/progrium We need to implement that inside
etcd. Since we have a list operation, which will leak the hidden path.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91#issuecomment-22464638
.

Jeff Lindsay
http://progrium.com

[xiang90]

@progrium I understand your suggestion. We may implement that in etcd first. Thanks.

[polvi]

This is definitely nice and simple. Thank you for the feeedback.

Would love your opinion on how to handle a scenario like this:

• Databases are able to do master election to promote a new master
• App servers only are able to read the current master, but cannot change it

[kapilt]

acls and namespaces are orthogonal. namespaces allow density and shared etcd resource infrastructure and isolation at an app level. acls do limited sharing and limit surface attack space for a client compromise within an app namespace. both are useful, zk does both as well.

[xiang90]

@kapilt We are working on that. And we will publish a spec soon. It will be a great help if you can help to review.

[kapilt]

@xiangli-cmu i'd be happy to review the spec.

[ericanderson]

Would love to see the spec as well.

[codeaholics]

This would be really valuable for us as well. We're building a PaaS-type deployment system in-house and are planning a shared etcd infrastructure where we give each app its own top-level folder to use at will. But there is currently nothing to stop an app reading/writing data outside its own top-level folder.

[neildunbar]

Adding to this on the mailing list, but I'm with @kapilt . Namespaces are more about localising the potential for mistakes. Not really about setting policy against malice.

[xeor]

Is this implemented and ready for primetime?
Based on the documentation I am finding @ https://github.com/coreos/etcd/blob/master/Documentation/api.md#creating-a-hidden-node putting a _ in front of a key will do exactly what we want..

Or did you just forget to close this issue?

[neildunbar]

No, I'm still working my test implementation for ACLs - haven't had time in last month to give it headspace. But I've got a few cycles this month.

[netkgk]

We're trying to adopt zookeeper to our needs, and find it completely useless. ACL, as it implemented in zookeeper, has no real application in heterogeneous environment with large number of users with different roles.
The only way etcd will be somehow useful for many people, is this approach: http://www.openldap.org/doc/admin24/access-control.html

It doesn't matter, how hosts get information from etcd, this is secure enough just as already is. What is really matter, is how this information gets in etcd. It is intended to use etcd for big clusters, right? So it must be a number of users, who are eligible to update information in the configuration storage, hence advanced ACL is required. When I say "advanced", I mean not just CRUD on the whole directory. But CRUD on each key by its name on different directories. For example, it should be possible to grant privileges on key "password" for all directories in the storage.

I can't see a point of inventing bicycle here, LDAP ACL implementation (unlike other LDAP stuff like schemas and so on) fit the bill just great. It requires only small simplification in that way so that privileges must be only granted on groups not for users or nodes.

I don't know why in unix-like operation systems it is even possible to set privileges directly for users (not for groups only), this is a blunder. It would be better to avoid this in etcd.

[kapilt]

netkgk.. this feels more like a rant than anything constructive or even concrete. your saying the unix fs acl model is not useful, and that anything that doesn't do file byte range/attribute access control across multiple directories isn't useful. Both of which are untrue. A rules based access system is more appropriate for a system built on top of etcd imo. I've found zookeeper's model to be quite flexible for application level security modeling in combination with the ability for a client's connection to have multiple attached principals (to model group access). if you really want ldap.. i'd suggest using that, and an app on etcd to keep the directory up-to-date based on presence.

[netkgk]

First of all, I don't want LDAP, it's too clumsy. Look at its schema thing, for example. What I need is up-to-date version of it. And etcd can be great replacement for it, but only if advanced ACL will be implemented.

Second, what purpose of making of clone of niche, weak designed product? Why don't you make a better solution?

Besides, I didn't say UNIX ACL model is not useful, I did say it is not flexible enough to serve as configuration storage.

[Asmod4n]

I believe what you are looking for is http://en.wikipedia.org/wiki/Capability-based_security

[justintime]

The ZK way of doing ACL's would provide me with just what I need. Here's the basic needs I have today:

1. I have 3 clusters: dev, stage, and production
2. Developers need to have RW permissions in dev.
3. Developers need to have RO permissions in stage and prod.
4. Puppet (or Chef, or whatever CM) will manage stage and prod, and will need a RW user for those 2 envs.
5. Applications (at this time) need RO access to all three env's.

As we use etcd more, I see the need to be able to write from the applications themselves, and namespacing would be a nice-to-have in such a case.

Other things to think about:

• How are you going to implement authentication for users? I'd prefer to just do basic auth from a flat file and manage that with Puppet.
• There may be use cases where it would be able to use an IP rather than a user. If you go this route, make sure to take into effect load balancers and the way they modify X-Forwarded-For.

[benmccann]

Before we have ACLs it seems we need to be able to authenticate multiple users. I've filed an issue for that here: #903

[flaviostutz]

I am modeling what will be a large Kubernetes cluster. When thinking about etcd security I am always concerned about "what if a container gets compromised by an attacker". On current model if the attacker manages to take over a container, he can damage the whole etcd directory, possibly denying all services on the Cluster just by removing/changing some entries. He will then possibly know all cluster topology based on records too. Current https certification doesn't help on this.

For now, I am thinking about using two separates containers on the same Kubernetes POD. One for the service itself (Node.js, TomEE etc) and the other for the etcd coordination, so that we can isolate possible services breakeages. This is very inconvenient and adds complexity to development.

Another choice is to create an intermediate server that receives containers commands and submits requests to the etcd cluster after validating what kind of changes are asked. We would have to create different services for each kind of rule. This is very controlled, but adds complexity too.

When thinking about the various use cases for containers that registers themselves on etcd or watches for changes on some parts of the directory so that they can perform self reconfiguration, the following features on etcd would help:

• A client can only read/write nodes from specific parts of the tree (traditional ACL)
• A client can only read/write nodes whose attribute "owner" matches its certificate Id. Limit the number of child nodes a client can create on a specific parent node
  - It is common for a unique client to just register itself on the directory, so there is no need to allow him to create more nodes, minimizing the possibilities of an attack

What do you think?

[jpettersson]

Any status on this?

I'm currently working on an in-house (but soon open source) PAAS setup using etcd and Helios. Deployments are defined as keys under a common namespace (deployments/specified/example.com) so that other system components (deployer, router) can watch and react on changes. The specifications are written directly by a CLI client that runs on the developer's workstation.

I need a multi user ACL solution where each deployment can be isolated and only accessed by the project members. Additionally, any member should be able to add/remove people to the project. Essentially I want to "chown" a certain path as accessible for a set of users.

The main reason for this feature is to reduce accidental deployments onto existing applications, not absolute security.

I'm thinking of writing a simple nginx based proxy and put it in front of etcd to handle the ACL myself. Is this a good idea? Or will the proposed ACL feature in etcd support my use case directly?

Great work with etcd, thanks!

[justintime]

We ultimately moved to Consul due to the lack of ACL's in etcd. It's web UI is functional, and the ACL's work as advertised. Nothing against etcd, we just found that etcd's primary goals were a bit different from ours, and Consul worked better for us. You might take a look into it.

[xiang90]

closed in favor of #2242