In this article, we will look at Datomic access control, covering
- authentication and authorization
- network-level access
- how the bastion works
- some example deployments
Authentication and Authorization
Datomic integrates with AWS
Identity and Access Management (IAM) for authentication and authorization, via a technique that we'll call S3 proxying. Here's how it works:
Every Datomic permission has a hierarchical name. For example, read-only access to database
Jan is named
access/dbs/db/Jan/read.
Permission names have a 1-1 correspondence with keys in the Datomic
system S3 bucket.
The Datomic client signs requests using AWS's
Signature Version 4. But instead of using your IAM credentials directly, the Datomic client uses your IAM credentials to retrieve a signing key from S3.
Thus, IAM read permissions of S3 paths act as proxies for Datomic permissions. As a result, you can use all of the ordinary IAM tools (roles, groups, users, policies, etc.) to authorize use of Datomic.
After decades of experience with racing to log into new servers to change the admin password, we think that this "secure by default" is pretty cool. But that is not the end of the story, as clients also must have network-level access to Datomic.
Network-Level Access
Datomic Cloud is designed to be accessed by applications running inside a VPC, and (unlike a service!) is never exposed to the Internet. You must make an explicit choice to access Datomic. You could:
Each of these approaches has its place for application access, and I will say more about them in a future article. For easy access to Datomic from a developer's laptop we offer the bastion.
How the Bastion Works
The
bastion is a dedicated machine with one job only: to enable developer access to Datomic. When you turn the bastion on, you get a barebones AWS Linux instance that does exactly one thing: forwards SSH traffic to your Datomic system.
To connect through the bastion:
- run the Datomic socks proxy script on your local machine
- add a proxy port argument when creating a system client
- the Datomic client sees the proxy port argument and connects to the socks proxy
- the socks proxy forwards encrypted SSH traffic to the bastion
- the bastion forwards Datomic client protocol traffic to Datomic
Access to the bastion is secured using the same IAM + S3 proxying technique used earlier for auth. The bastion has an auto-generated, ephemeral private key that is stored in S3 and secured by IAM.
The bastion is dynamic, and you can
turn it on or off an any time. And the client support means that the bastion is entirely transparent to your code, which differs only in the argument used to create the client.
A Concrete Example
As a concrete example, here is how the
Datomic team configures access for some of our Datomic systems:
Our 'ci' system is dedicated to continuous integration, supporting several dozen Jenkins projects. The ci system contains no sensitive data, only canned and generated examples. The ci system runs the
Solo Topology with the bastion enabled to allow access by automated tests.
Our 'devdata' system contains non-sensitive data used by the development team (think departmental and sample apps). The devdata system runs the Solo Topology with the bastion enabled to allow access by developers.
Our 'applications' system supports applications and contains real-world data. The applications system is reachable only by deployed application code, and needs to be highly available. So the applications system uses the
Production Topology with the bastion disabled, and also uses fine-grained IAM permissions to limit applications to the databases they need.
Conclusion
Datomic is secure by default, integrating directly with AWS IAM and VPC capabilities. The bastion makes it easy for developers to get connected, so you can be up and transacting on a new system in minutes.
To learn more, check out
Or just
dive in and get started.
..
