We at Determinate Systems are super excited to announce the private beta of FlakeHub Cache, a fresh new take on Nix caching featuring fine-grained access control and authentication based on JSON Web Tokens. Our announcement post:
Unlike other caching solutions that serve up a Nix store as a single monolithic caching unit, FlakeHub cache offers a much more robust permissions system, with the Nix flake as the unit of access control. You can assign read and write access to specific flakes to users however you wish, providing a model that scales seamlessly across orgs and teams.
And instead of public and private keys, FlakeHub Cache uses JSON Web Tokens (JWTs) for authentication. This means that FlakeHub Cache will be able to integrate with a vast array of auth solutions, including SAML and various Single Sign-on (SSO) providers.
Push access to FlakeHub Cache is currently available only in GitHub Actions (with GitLab support coming soon), as we’ve initially opted for a model that heavily favors trusted automated builders over ad-hoc access.
We are actively seeking community feedback so please do sign up for the beta if interested. If you have any questions, feel free to talk to us on Discord in the #flakehub-cache room.
Eelco, the DetSys team, and I have been hard at work on FlakeHub Cache for some time now. Our mission has been to support taking Nix to work. FlakeHub Cache is SOC2 compliant, and its cloud native authentication model pairs great with the Determinate Nix Installer and its MDM mode + SCIF support. This is another important component for a successful rollout across organizations and teams. I’m happy to answer questions!
For platforms that use oidc for identity federation this is awesome. (E.g. google cloud and Kubernetes) . You can make sure that only specific service account can pull from cache. And set up deploys to machines without any static credentials whatsoever. Super exciting.
Im on AWS myself and use an S3 Cache with IAM roles for similar effect except that the access control policies AWS gives are obviously not aware of things like flakes and nix closures. So can’t write as granular permissions. So this sounds like an exciting improvement.
Would be great to also support AWS IAM Roles through STS:GetCallerIdentity next to OIDC for authentication such that AWS workloads can also pull from cache without any static credentials . As AWS doesn’t use JWTs for workload identity unfortunately. There are workarounds like creating a cognito identity pool to mint id tokens for IAM roles but they’re a bit hacky.
Excited to see this kind of deep integrated products that are using workload identities instead of static credentials. This is the best way to do things. The best secret is no secret
Can you say anything on how the mapping from a flake to the store view works? Is this for flakes in general, or ones that have been registered on FlakeHub?
In nixbuild.net this kind of “slicing” is based on signing keys (your view of the store changes based on the set of public keys you trust), I’m just curious on how FlakeHub Cache works
FlakeHub Cache is available only to flakes published to FlakeHub (we do support private flakes, so publishing doesn’t mean “making public” per se).
Basically, each flake gets a slice of the store and each user has access to some set of those slices. The sum total of those available slices we call a view of the cache. So if I’m working for OmniCorp, my manager may decide that I have pull access to flakes A and B but not C (A and B would be my view of the cache in this case).
Who you are can be determined by the contents of your netrc file, so it’s roughly analogous to systems that enable you to distribute API keys, though just using plain old Nix. You run fh login (fh is the CLI for FlakeHub), create a token in the FlakeHub dashboard, and then you copy/paste a few lines into the netrc. We’re working on making this smoother but the CLI does provide you copy/pastable lines.
In terms of keys, you do need to provide two public keys for cache.flakehub.com in your nix.conf but those are the same for everyone, and those keys don’t determine which view you have access to.
As for push access, that can only happen in CI (GitHub Actions now, GitLab soon, others later), so there’s no ad-hoc push access whatsoever.
If anyone finds it interesting, here is an example of a policy you can attach to your nixbuild.net access token to limit access to store paths that has been signed by a specific signing key: Access Control - nixbuild.net documentation
Shoot. I just realized we didn’t put the right data on the pricing page. We typed it all out in our planning document, but it didn’t translate to the page :'). Sorry, and thank you for pointing that out! We’re right about to push an update to fix that. UPDATE: Fixed.
In the short term, we don’t bill for it at all. But only because we haven’t hooked up the metrics database to billing. Please don’t hurt me . FlakeHub Cache is essentially market rate for storage and bandwidth. We’re not looking to make our money on undifferentiated bytes-on-disks.
. As AWS doesn’t use JWTs for workload identity unfortunately. There are workarounds like creating a cognito identity pool to mint id tokens for IAM roles but they’re a bit hacky.
. FlakeHub Cache is essentially market rate for storage and bandwidth. We’re not looking to make our money on undifferentiated bytes-on-disks.