authzed / zed Goto Github PK
View Code? Open in Web Editor NEWOfficial command-line tool for managing SpiceDB
Home Page: https://authzed.com/docs/reference/clients
License: Apache License 2.0
Official command-line tool for managing SpiceDB
Home Page: https://authzed.com/docs/reference/clients
License: Apache License 2.0
Trying to delete a relationship, with the following command:
zed relationship delete btwb_development/document:firstdoc reader btwb_development/user:fred
returns the error
Error: rpc error: code = InvalidArgument desc = invalid WriteRequest.Updates[0]: embedded message failed validation | caused by: invalid RelationTupleUpdate.Tuple: embedded message failed validation | caused by: invalid RelationTuple.ObjectAndRelation: embedded message failed validation | caused by: invalid ObjectAndRelation.Namespace: value does not match regex pattern "^([a-z][a-z0-9_]{2,62}[a-z0-9]/)?[a-z][a-z0-9_]{2,62}[a-z0-9]$"
The following cli command:
zed relationship delete document:firstdoc reader user:fred
Works
The zed command currently only uses the system certificate store; However, it's easy enough under the authzed operator to use an internal CA to sign serving certificates. It would be helpful to be able to debug those with the standard zed command.
relationship.go has a bug where it's not able to parse the --caveat caveatname:json value properly.
the fix should be
replace line no-267
parts := strings.Split(caveatString, ":")
with
parts := strings.SplitN(caveatString, ":",2)
I just tried to install zed on Ubuntu / Debian headless via homebrew and the .deb package.
Unfortunately upon running zed context set local localhost:50051 "somerandomkeyhere" --insecure
I get a promt to set a keyring password. Well, I have never set a password and am not using Keyring.
The output I get is:
Entering your password a lot? Try setting the environment variable `ZED_KEYRING_PASSWORD`
Enter passphrase to unlock "/home/XYZ/.zed/keyring.jwt":
I don't now the password though as I have never set it and entering nothing or a random string all leads to an error.
I would expect the documentation to work which just states for macOS and Linux:
brew install zed
zed context set local localhost:50051 "somerandomkeyhere" --insecure
zed schema read --insecure
https://authzed.com/docs/spicedb/installing#running-via-brew
This might be related to #140.
If keyring is required, this would basically make zed useless in any headless setup I believe.
mac OS version: 11.6.2
on build of cmd i get:
# github.com/keybase/go-keychain
cgo-gcc-prolog:203:11: warning: 'SecTrustedApplicationCreateFromPath' is deprecated: first deprecated in macOS 10.15 - No longer supported [-Wdeprecated-declarations]
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrustedApplication.h:59:10: note: 'SecTrustedApplicationCreateFromPath' has been explicitly marked deprecated here
Maybe we still need to have this to support old versions of Mac OS ?
The determinePrefixForSchema
check in schema.go
will fail on write and/or copy commands for schemas that have multiple prefixes within.
For example, in a schema that utilizes spicedb if there are definitions such as :
company/user company/ldap_group serviceA/items serviceB/accounts
where in serviceB/accounts
there is a relation owner : company/user | company/ldap_group#member
a zed schema write ${file}
fails in the determinePrefixForSchema
due to the multiple prefixes in the schema.
I understand from a discord discussion that this is a protective/sanity check for Authzed schema requests. Maybe a --skip-prefix-check
flag for local spicedb schema manipulation?
The currently build zed container images based on distroless which ships an extremely minimal environment (it doesn't even include a shell).
Would be really if you could offer variants of your images using the distroless debug base so that debugging is as simple as changing their image name to authzed/spicedb:$VERSION-debug.
analog to this topic:
authzed/spicedb#749
Relationship read with optional_relation, optional_subject_type and optional_subject_id is not return correct result.
e.g following query will return all virtue cards with parent relation. Not all virtual cards with parent relation under creditcard:cc_9MSTeIVLW0C6aHtiQSolob
zed relationship read virtualcard parent creditcard:cc_9MSTeIVLW0C6aHtiQSolob --insecure
def user{}
def account {
relation owner: user
permission read = owner
}
definition creditcard {
relation parent: account
relation owner: user
relation viewer: user
permission read = owner + viewer + parent->read
permission destroy = owner
}
definition virtualcard {
relation parent: creditcard
relation recipient: user
relation viewer: user
permission read = recipient + viewer + approver + parent->read
permission spend = recipient
permission requestupdate = recipient
}
A command is missing to expose the functionality from the Lookup API.
This API call lists the objects of a given type that a user has access to in a Permissions System.
A strawman for how it could be exposed it via the CLI:
zed relationship lookup user:emilia posts:read
Object IDs with pipe characters fail to validate and import.
For example: organization:org_f00bar#member@user:auth0|f1zzbuzz
fails validation, but organization:org_f00bar#member@user:auth0_f1zzbuzz
passes.
It looks like this has already been fixed in this fix in SpiceDB.
I think the only thing needed here is to update the package dependency on github.com/authzed/spicedb from 1.4.1 to 1.5.0.
I took the example RBAC schema and intentionally made an error by changing relation writer: user
to relation writer: undefined
. https://play.authzed.com/s/x1jQ10YQkoHl/schema
The authzed playground correctly underlined the "undefined" on line 13 as the error.
If you download the file and then run zed validate
on the downloaded file, the line that gets highlighted is actually the line above the error, which is line 13 of the yaml file, rather than of the schema.
If you rearrange the keys of the yaml file, you will see that it will always mark the Nth life of the yaml file where N is the line of the schema where there is an error, rather than the line that actually contains the error.
Should mirror the copy
command under schema
The last part in https://docs.authzed.com/guides/first-app suggests to run 4 command like
zed permission check blog/post:1 read blog/user:emilia --revision "${ZEDTOKEN}" # true
I take that I am suppose to use the taken here as revision (which I did). I am running a local SpiceDB instance (in minikube).
For the above command I get this error:
Error: rpc error: code = Unavailable desc = last connection error: connection error: desc = "transport: Error while dialing dial tcp 192.168.9.1:50053: connect: connection refused"
Usage:
zed permission check <resource:id> <permission> <subject:id> [flags]
...
The other terminal running the kubectl port-forward
shows that it handled a connection attempt.
Versions:
zed --skip-version-check version
client: zed 0.7.5
service: v1.11.0
Also other commands do work:
zed relationship read 'blog/post'
blog/post:1 reader blog/user:beatrice
blog/post:1 writer blog/user:emilia
A command to list all (or a portion of) the relationships in a Permissions System needs to be added.
There are a variety of ways it could be exposed it via the CLI:
zed permission read <expr>
zed relationship read <expr>
zed relationship list <expr>
This would be a relatively minor QOL thing from an end-user perspective, but given that zed permission check --explain
can tell me all of the relations that led to a positive check, it'd be cool to have that output on failed assertFalse
assertions, where the permission check was true.
Hey,
I'm trying to run a couple zed
commands in a Kubernetes job using the zed
Docker image.
The recommended way to do this seems to be
command: ["/bin/sh","-c"]
args: ["zed command_1; zed command_2"]
However, I noticed the base image for the container doesn't have a shell available (or im unable to find it?)
What's the recommended way of running multiple commands on the container?
Using quay.io/authzed/zed:0.5.0
since im still running into this issue with other versions
zed version: zed 0.1.2
system: window 10 64
use command "zed schema read", there is error info :
panic: crypto/x509: system root pool is not available on Windows
goroutine 1 [running]:
github.com/authzed/grpcutil.WithSystemCerts(0x40)
/Users/runner/go/pkg/mod/github.com/authzed/[email protected]/dial_opts.go:28 +0x49
main.dialOptsFromFlags(0xacba20, {0xc00048e000, 0x10})
cmd/zed/main.go:37 +0x40a
main.schemaReadCmdFunc(0x134a6a0, {0x13bb5f8, 0x0, 0x0})
cmd/zed/schema.go:69 +0x245
github.com/spf13/cobra.(*Command).execute(0x134a6a0, {0x13bb5f8, 0x0, 0x0})
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:856 +0x60e
github.com/spf13/cobra.(*Command).ExecuteC(0xc0003ecf00)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:902
main.main()
cmd/zed/main.go:93 +0x459
This requires some backend changes to the Authzed dashboard, but the end UX can be discussed here.
For users without a keychain, zed encrypts a file in ~/.zed
. I think right now it's possible to accidentally enter your initial password as empty string, which breaks future attempts to decrypt.
This bug needs to be reproduced first and then addressed. We can probably just retry the password prompt if we get an empty password.
First off, SpiceDB is very cool and seemingly the best Zanzibar implementation there is. Thanks for that! It's a fun product that I'm still wrapping my head around. Now, a quick story.
Last night while trying to debug a kubernetes deployment, I realized zed
was hanging on any usage of the context
command to manage credentials while trying to interface with the service. It was completely bizarre, and looked like this (after a kubectl proxy
):
$ zed --no-verify-ca --insecure --log-level trace context set local grpc://127.0.0.1:50051 <xyz>
9:03AM DBG set log level new level=trace
In fact it was so bizarre because I had used zed
previously, on another machine, to test a docker container. And I did that again to be sure I wasn't losing it, and it was just fine. It prompted me for a password for the JWT keys; I remembered that. So what could be the problem? I tried strace
and nothing immediately popped out; it was waiting on a futex, which almost always means waiting on some IPC or lock mechanism; unfortunately a futex is too low level to work off of. I read the manual and saw that it integrates with the system keyring, but just writes JWT files according to the go keyring package. I confirmed it wrote those JWT files on my working machine. The source code (when I read it) seemed innocuous enough. But I couldn't figure it out.
So I went to sleep, and this morning while getting coffee it dawned on me: I thought of the words "GNOME Keyring", and realized the system where the hang occurs has a full GUI (desktop environment) active. More precisely, it is an Ubuntu Virtual Machine running a GNOME desktop (I need GNOME for some proprietary software to run its user interface on this machine). But I develop on this machine by using vscode
with its powerful SSH integration to help desktop GUI latency/my Mac has better font rendering. On the other hand, the system where zed
worked was completely headless and had no UI active at all. GNOME Keyring will prompt you for encryption passwords via the UX if, and only if, the GUI is active.
Sure enough, this morning I sat down, sat at VSCode on my Mac, typed in the words zed context set local ...
and the hang started. I moved over and opened my Ubuntu Virtual Machine, and sure enough, the culprit causing the hang reveals itself:
So I honestly don't know what to do here because the actual thing is, everything is "Working as expected." So the problem is:
keyring
, appears to hangBut this is all by design. It's kind of expected that if the desktop was open, you'd be using it. However it's extremely non-intuitive is this happens when you aren't using the desktop, because there is literally no possible way to tell if anything is happening.
Maybe it would be possible to just add more tracing messages, honestly? The fact I couldn't even tell what zed context
was trying to do until I refreshed my memory (by using zed context
successfully on the other machine) made it hard to figure out what might be happening.
There is also the more broad question of authenticating with SpiceDB in the long run. While I understand SpiceDB occupies a special infrastructural role — it being used to build your auth infrastructure means "self bootstrapping" user authorization is tricky — I suspect a simple pre-shared bearer token won't work for everyone, forever; but it is simple. So in the future assuming basic authentication came from some other mechanism the keyring might instead be avoided entirely, making this moot. I don't know (e.g. the simplest case would be to configure a CA and only allow clients with a signed proper TLS cert to connect; or ed25519, etc...)
One case I haven't checked is that my Desktop UI was actually logged into GNOME; it might be the case that if your user doesn't have a desktop login session available, then the keyring will be prompted remotely over the terminal instead (because there is no working display server for the user.) I'll test this just to be sure...
Strawman design:
zed schema write https://play.authzed.com/s/deadbeefdad
Right now the context stores everything I need to talk to Authzed.com or a local SpiceDB except whether that connection should use TLS or not. This means that every zed request to SpiceDB needs the --insecure
flag. This flag should be stored along with the rest of the context because it doesn't regularly change for a context.
The JSON output of zed expand
returns something like:
{
"expandedAt": {
"token": "GgMKATY="
},
"treeRoot": {
"expandedObject": {
"objectId": "aae48b55-ad96-11eb-a562-06368a59bfb7",
"objectType": "care_recipient"
},
"expandedRelation": "agency",
"leaf": {}
}
}
Whereas the API returns, for the same request:
{
"expandedAt": {
"token": "GgMKATY="
},
"treeRoot": {
"treeType": {
"oneofKind": "leaf",
"leaf": {
"subjects": []
}
},
"expandedRelation": "agency",
"expandedObject": {
"objectType": "care_recipient",
"objectId": "aae48b55-ad96-11eb-a562-06368a59bfb7"
}
}
}
In the zed
response, we do not have the treeType
attribute
Would be nice to have an option to tell a context in general to not verify CA.
I receive the following message when trying to run either of them without any arguments:
$ docker run --rm -t -i quay.io/authzed/zed # :latest, :v0.7.0 and :v0.6.0 all return the same result
exec /usr/local/bin/zed: no such file or directory
$ docker run --rm -t -i quay.io/authzed/zed:0.5.0
A client for managing Authzed from your command line.
Usage:
zed [command]
Available Commands:
[...]
Many tools (e.g. homebrew) have a doctor
command that evaluates the state of the world and prints useful warnings.
Pressing tab after zed use
or zed context use
should shell complete to the available contexts.
➜ project git:(branch) ✗ zed version
client: zed v0.9.1
1:26PM WRN the version of SpiceDB being called is out of date. See: https://github.com/authzed/spicedb/releases/tag/v1.17.0 latest-released-version=v1.17.0 this-version=v1.14.0
service: v1.14.0
➜ project git:(branch) ✗ zed permission lookup-subjects site:my_site granted role_binding
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x30 pc=0x100f90e30]
goroutine 1 [running]:
github.com/authzed/zed/internal/commands.lookupSubjectsCmdFunc(0x101e22700?, {0x1400056c1e0, 0x3, 0x3?})
internal/commands/permission.go:416 +0x470
github.com/spf13/cobra.(*Command).execute(0x101e22700, {0x1400056c150, 0x3, 0x3})
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:916 +0x5c8
github.com/spf13/cobra.(*Command).ExecuteC(0x1400028e000)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1044 +0x35c
github.com/spf13/cobra.(*Command).Execute(...)
/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:968
main.main()
cmd/zed/main.go:70 +0x510
I have a site
with a relation to a role_binding
and not a whole lot else in my system. I'll try upgrading the CLI, and if that doesn't work, I'll try upgrading SpiceDB.
We're forcing "AtLeastAsFresh" when a Zed Token is provided, but rather, there should be a flag to specify the other consistency options.
See:
zed/internal/storage/config.go
Line 46 in f0f9fbc
$ brew install --HEAD zed
==> Cloning https://github.com/authzed/zed.git
Updating /Users/jzelinskie/Library/Caches/Homebrew/zed--git
From ssh://github.com/authzed/zed
838b4a2..c3f2000 main -> origin/main
==> Checking out branch main
Already on 'main'
Your branch is behind 'origin/main' by 51 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
HEAD is now at c3f2000 Merge pull request #41 from ecordell/release
==> Installing zed from authzed/tap
Error: An exception occurred within a child process:
Errno::ENOENT: No such file or directory - zed
zed schema read > my_schema.txt
# edit the schema ...
zed schema write my_schema.txt
zed schema write my_schema.txt
{"level":"fatal","error":"rpc error: code = InvalidArgument desc = error parsing schema: parse error in `schema`, line 1, column 1: Unexpected token at root level: TokenTypeLeftBrace","time":"2021-10-28T10:36:37+02:00","message":"failed to write schema"}
This is because whenever zed
detects a fd
it will switch to JSON/pretty mode. This makes scripting things hard.
Either make formats explicit and don't do autodetection or be compatible when piping/reading into zed
.
In order to help debug clusters without access, there could be a command that collects up as much debug information as possible and sanitizes it.
This idea was inspired by https://github.com/coreos/mayday
When one edits a schema in the playground then imports it back into a permissions system via the "import" button, the playground automatically prepends the permission system's prefix to each reference in the schema.
However, that rewrite doesn't happen on zed import
operations, making it difficult to share a common schema file with multiple permission systems; each reference in the schema has to be manually modified to include the prefix for the destination permission system.
This is a request to either:
The default Authzed endpoint should include the port, otherwise it fails:
$ ./zed describe skynet_dev
Error: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: lookup grpc.authzed.com: no such host"
It should be configured to use grpc.authzed.com:443
by default.
There needs to be a GitHub action on this repository that uses action-spicedb for end-to-end testing of the CLI commands and flags.
I was trying to use zed validate
in a pipeline that didn't support color output, but when displaying schema syntax errors, there is no way to tell which line is causing issues.
error: could not lookup definition `undefined` for relation `writer`: unknown
definition undefined
11 | /**
12 | * writer indicates that the user is a writer on the document.
13 | */
14 | relation writer: undefined
15 |
16 | /**
Suggested fix:
Either by default or with a CLI flag, use a >
to indicate the failing line:
error: could not lookup definition `undefined` for relation `writer`: unknown
definition undefined
11 | /**
12 | * writer indicates that the user is a writer on the document.
13 | */
14 > relation writer: undefined
15 |
16 | /**
The LookupSubjects API is now available, so we should add the command to zed
If we are using zed against authzed.com we can not use the "--explain" flag in a permission check.
There is always this error:
INF debugging requested on check
WRN No debuging information returned for the check
Error: rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: NO_ERROR
We are using zed via brew on an apple m1.
We're using revive right now for linting in the build workflow, but it's also not configured to fail if anything is wrong.
Here's the config we use in SpiceDB:
- uses: "golangci/golangci-lint-action@v2"
with:
version: "v1.42"
skip-go-installation: true
skip-pkg-cache: true
skip-build-cache: false
The printers.PrintTable
function ignores its io.Writer
argument, always writing to os.Stdout
instead.
It doesn't seem to be causing any issues at the moment -- all call sites pass os.Stdout
anyway -- but it didn't look like it was intentional either.
zed import
currently constructs a single WriteRelationships
call, which will be exceeded after ~5000 relationships. We should add support for batching the relationships to be imported into chunks, and executing those chunks in parallel.
As mentioned in Discord (https://discord.com/channels/844600078504951838/844600078948630559/949071336574181457), there are a number of issues to address:
- The gRPC server has a limit on message sizes. This can easily be solved by batching the requests
- Batching is tricky, serially executing each batch works to an extent, but it's not very scalable. This could be improved by executing each batch in a goroutine. Of course, this comes with some risk, as there's roughly a 9k batch size limit (see 3). If a zed import is trying to import 6 million+ rows, that's about 650 connections each trying to shove through 9k tuples.
- Postgres and MySQL both have a limit on how many placeholders you can have in a single query. This appears to be 65535 for Postgres and MySQL (https://stackoverflow.com/a/49379324, https://stackoverflow.com/a/24447922). This roughly translating to a maximum of 9362 relationship tuple writes (assuming each is going to require 7 placeholders). I didn't initially hit this limitation because I was testing with an in memory database.
We'll need to see a reasonable limit on the number of parallelized write requests, have a progress bar for display, etc
In order to more effectively benchmark or assert the liveliness of a deployment, zed should have a command that generates traffic.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.