awesome!

hello are all recent official SpiceDB docker images "distroless"? i noticed that newest official spicedb images do not have

/bin/sh

and i was wondering whether a version with a shell is also available. I think that it might be a good idea to include shell along with existing tools. overall, a small image is great. however, to do something like:

ENTRYPOINT spicedb serve --grpc-preshared-key "${SECRET}"

we need

/bin/sh

. currently, this won't work and it makes passing environmental variables a pain. unless someone worked out another way to do this. i would be certainly interested to know to pass environmental variables to the dockerfile entrypoint without a shell.

You can use the docker env to pass command line flags, using their flag equivalent

SPICEDB_GRPC_PRESHARED_KEY

in this case

meaning that the below should work:

FROM authzed/spicedb:v1.12.0

ARG SPICEDB_GRPC_PRESHARED_KEY
ENV SPICEDB_GRPC_PRESHARED_KEY=${SPICEDB_GRPC_PRESHARED_KEY}

ENTRYPOINT ["spicedb", "serve", "--grpc-preshared-key", "--http-enabled"]

EXPOSE 8443/tcp 50051/tcp 8080/tcp 9090/tcp

There are also “debug” versions of the images that do have a shell, like authzed/spicedb:v1.12.0-debug. But as Jake said, you shouldn’t need them for setting flags

@Jake i tried it now and it is not working

You shouldn’t really need your own dockerfile

why not?

Because the versions we built can be run out of the box

something like

docker run -e SPICEDB_GRPC_PRESHARED_KEY="abc" authzed/spicedb:v1.12.0

i want to use your image as the base -

FROM

and pass secrets including database config in build arguments

without a custom dockerfile, i cannot do that

i don't need this to run locally, but it will help a lot when i run it under fargate

if you pass secrets in as builder args they get embedded into the container image, which means that your container images now contain secrets too and must be managed as secrets

as, correct

and i am fine with this

every image in almost every production environment in the world gets built like this

right?

ok, then with your dockerfile above, try just removing the

spicedb-grpc-preshared-key

command line argument

no, none of our images have secrets, the secrets get injected through the env with kubernetes secrets

i understand

Hello all. A question since I feel that I may be missing something. Is there support for checking a relationship/permission of a subject for all resources of a specific type?

Usually you will check if a user can create a resource on a higher level containing resource that exists in the system and for which the user has some relationship. This could even be a platform singleton.

Like you can ask: can this user create a new document in this folder?

In this case, I can use something like a "root" resource for my application and add permissions there, as you suggest. Clear 🙂

I was able to build a cloudformation config for Fargate communicating gRPC without the need for an HTTP proxy. It does health checks on gRPC as well. currently, only API is exposed to the outside - port

50051

. Should not be too difficult within reason to add mappings for 8080 and 9090, as well. Happy to share my findings, if this might help someone, as a reference for their ECS clusters. In my experience, often, it is easier to throw containers on Fargate and not having to worry about managing a full K8s cluster.

I think a fargate example would go great in our examples repo: https://github.com/authzed/examples

would you be willing to open a PR?

i will check your contributing or wherever the process is covered