Security

[petermattis]

[This will likely spawn a host of sub-issues]

• [ ] Authentication
  • [x] Username/password
  • [x] X.509 Certificate
  • [ ] Kerberos
  • [ ] LDAP
  • [ ] PAM
• [ ] ACLs (Database, Table, Column)
• [ ] Fine-grained permissions (macaroons)

[cloudmode]

I hope all these 'features' default to 'none' or 'false' or whatever. Models built on top of cockroach will have their concepts of security. Anything beyond Authentication is a waste of resources and energy for the physical storage layer, particularly trying to to anything with LDAP. I think that the layer on top of cockroach, should be responsible for security/control.

[mrtracy]

There is probably a good argument for disabling authorization by default, which will ease the initial setup and deployment for developers, especially in small test environments. I'm not sure if we should allow anonymous authentication, but that's also a possibility if it helps people onboard.

However, Cockroach is intended to be a multi-tenant system; even if a cluster is used by a single organization, we would expect the same cluster to be used by multiple applications of the same organization. Unless you are willing to trust all of these applications to be free of injections or exploits, database level authorization is a necessity in production deployments.

So while a default of "off" is probably a good decision, authorization needs to be available, easy to enable, and difficult to circumvent.

[petermattis]

@cloudmode What is the layer on top of cockroach that you're envisioning would handle security/control?

The terseness of the issue might have led to a bit of confusion. As Matt said, Cockroach is going to be multi-tenant. If you have a shared database system (e.g. MySQL, Postgres, etc) you don't want user A to be able to read or write user B's data without permission. The database itself needs to enforce this. That's the ACL and permissions bit. And in order for that access control to be meaningful you need to be able to identify users in order to determine what controls to apply.

I'm having trouble imagining a scenario where Cockroach does not provide any authentication or authorization, but please share what use case you have in mind and where you see Cockroach living in the application stack.

[cloudmode]

Our architecture is based upon a physical key-value store that never sees the light of day. There are a set of micro-services that manage the model layer on top of this physical key-value store. These micro-services are the only clients of the key-value store. There are application servers that layer on top of the micro-services, and these are permissioned by one of the micro-services. We use a very non-traditional authentication service. From there, authorization is implemented at the model layer, whether at the object, or attribute level. Authorization controls are done semantically, and can either be static (defined as attributes in the object), or closed dynamic (authorization granted on the context of the request) or open dynamic (a structured data transaction, identifying conditions/terms/rules that are external to the object being accessed). That's all wrapped up in an immutable chain used for auditing, etc.

Previously we were using FoundationDB, and their philosophy was that their key-value store should never be accessed from outside a firewall, and that all access should be constrained to clients that were specifically provisioned/maintained via the firewall.

I would suggest that a multi-tenant model would be best implemented as a layer above cockroach, that offered those type of security services, as they are actually a function of the model. You use MySQL/Postgres as an example. I don't see cockroach as being analgous at all. We view databases like MySQL/Postgres as an amalgam of physical storage, data model and query language. So the data model of MySQL/Postgres (the table with rows and columns) is responsible for access control.

It all comes down to separation of concerns, and the conflation of authentication and access control issues creates big security issues, and is best handled above the physical storage layer.

[petermattis]

So any of your micro-services can access all of the data stored in the physical key-value store? That sounds like a recipe for disaster as a bug in one micro-service can accidentally delete data used by another.

Even if the database cannot be accessed outside of your firewall, that doesn't mean that all of your internal applications or users should be treated equally. Some users might be privileged (e.g. sysadmins) and some applications might be storing sensitive data (e.g. credit cards, personally identifiable information). Yes, this can all be built on top of the key-value layer, but why shouldn't the database provide it?

I think we'll have to agree to disagree about how multi-tenant Cockroach should be implemented. Regardless, this shouldn't get in your way as you'll be able to configure Cockroach so that a single user has access to everything, just as you can with MySQL/Postgres/etc.

[cloudmode]

Technically yes, however by convention each microservice prepends all keys with the name of the microservice. Cool, as long as we can turn it off. The alternative I supposed would be to create actual namespaces that a client accesses, which is what I have effectively done. You'll have to do that for the multi-tenant thing anyway I suppose.

[petermattis]

You want your database to enforce permissions (especially in a micro-services world) so that the equivalent of an errant rm -fr / does not destroy the world. Saying "that can't happen to me" is fine for an individual company to make, but leaves a bad taste in my mouth for a database, filesystem or other storage system.

[cloudmode]

I get it. The question for me is at what layer I want the complexity to reside. Since there are so many complexities, there are many different answers.

[petermattis]

Closing this old pseudo-roadmap issue.