Some checks failed
codecov / upload (push) Failing after 13m59s
CodeQL / Analyze (push) Failing after 1s
Testing / vet-proto (push) Failing after 1s
Testing / tests (arm, latest) (push) Waiting to run
Testing / extras (latest) (push) Failing after 1s
Testing / static checks (latest-1) (push) Failing after 1s
Testing / tests (-race, latest) (push) Failing after 1s
Testing / tests (i386, latest) (push) Failing after 1s
Testing / tests (latest) (push) Failing after 1s
Testing / tests (latest-1) (push) Failing after 1s
Lock Threads / lock (push) Failing after 1s
govulncheck / govulncheck (.) (push) Failing after 1s
govulncheck / govulncheck (./cmd/protoc-gen-go-grpc) (push) Failing after 1s
govulncheck / govulncheck (./gcp/observability) (push) Failing after 1s
govulncheck / govulncheck (./security/advancedtls) (push) Failing after 1s
govulncheck / govulncheck (./stats/opencensus) (push) Failing after 1s
Stale bot / stale (push) Failing after 1s
76 lines
2.6 KiB
Markdown
76 lines
2.6 KiB
Markdown
# RBAC authorization
|
|
|
|
This example uses the `StaticInterceptor` and `FileWatcherInterceptor` from the
|
|
`google.golang.org/grpc/authz` package. It uses a header based RBAC policy to
|
|
match each gRPC method to a required role. For simplicity, the context is
|
|
injected with mock metadata which includes the required roles, but this should
|
|
be fetched from an appropriate service based on the authenticated context.
|
|
|
|
## Try it
|
|
|
|
Server is expected to require the following roles on an authenticated user to
|
|
authorize usage of these methods:
|
|
|
|
- `UnaryEcho` requires the role `UNARY_ECHO:W`
|
|
- `BidirectionalStreamingEcho` requires the role `STREAM_ECHO:RW`
|
|
|
|
Upon receiving a request, the server first checks that a token was supplied,
|
|
decodes it and checks that a secret is correctly set (hardcoded to
|
|
`super-secret` for simplicity, this should use a proper ID provider in
|
|
production).
|
|
|
|
If the above is successful, it uses the username in the token to set appropriate
|
|
roles (hardcoded to the 2 required roles above if the username matches
|
|
`super-user` for simplicity, these roles should be supplied externally as well).
|
|
|
|
### Authorization with static policy
|
|
|
|
Start the server with:
|
|
|
|
```
|
|
go run server/main.go
|
|
```
|
|
|
|
The client implementation shows how using a valid token (setting username and
|
|
secret) with each of the endpoints will return successfully. It also exemplifies
|
|
how using a bad token will result in `codes.PermissionDenied` being returned
|
|
from the service.
|
|
|
|
Start the client with:
|
|
|
|
```
|
|
go run client/main.go
|
|
```
|
|
|
|
### Authorization by watching a policy file
|
|
|
|
The server accepts an optional `--authz-option filewatcher` flag to set up
|
|
authorization policy by reading a [policy
|
|
file](/examples/data/rbac/policy.json), and to look for update on the policy
|
|
file every 100 millisecond. Having `GRPC_GO_LOG_SEVERITY_LEVEL` environment
|
|
variable set to `info` will log out the reload activity of the policy every time
|
|
a file update is detected.
|
|
|
|
Start the server with:
|
|
|
|
```
|
|
GRPC_GO_LOG_SEVERITY_LEVEL=info go run server/main.go --authz-option filewatcher
|
|
```
|
|
|
|
Start the client with:
|
|
|
|
```
|
|
go run client/main.go
|
|
```
|
|
|
|
The client will first hit `codes.PermissionDenied` error when invoking
|
|
`UnaryEcho` although a legitimate username (`super-user`) is associated with the
|
|
RPC. This is because the policy file has an intentional glitch (falsely asks for
|
|
role `UNARY_ECHO:RW`).
|
|
|
|
While the server is still running, edit and save the policy file to replace
|
|
`UNARY_ECHO:RW` with the correct role `UNARY_ECHO:W` (policy reload activity
|
|
should now be found in server logs). This time when the client is started again
|
|
with the command above, it will be able to get responses just as in the
|
|
static-policy example.
|