You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the number of consumers has grown & the ability to do so is not restricted we've been unable to keep track. When an issue arises or we have to coordinate changes (for example, as we've been making changes to the underlying nats streaming cluster) it's been helpful to chat with other teams/consumers.
An identifier could also be used in metrics (who's consuming/publishing the most) or logs (which client caused a repeatable server panic).
I played with 2 ideas for identifying a client
Client ID. An identifying token over a gRPC TLS connection.
Mutual TLS. Identify the client through the cert.
ACL
The main driver for authentication has been to implement ACL on the publishing side of things. We should be able to restrict who can publish back into the stream.
An example spike looks like...
funcNewStreamServerInterceptor(authauthorisor) grpc.StreamServerInterceptor {
returnfunc(srvinterface{}, stream grpc.ServerStream, info*grpc.StreamServerInfo, handler grpc.StreamHandler) error {
newCtx, err:=auth.Authorise(stream.Context(), info.FullMethod)
iferr!=nil {
returnerr
}
wrapped:=grpc_middleware.WrapServerStream(stream)
wrapped.WrappedContext=newCtxreturnhandler(srv, wrapped)
}
}
func (a*BasicAuthorisor) Authorise(ctx context.Context, methodstring) (context.Context, error) {
if!a.SecureConsume&&!a.SecurePublish {
returnctx, nil
}
token, err:=grpc_auth.AuthFromMD(ctx, "basic")
iferr!=nil {
returnnil, err
}
client, err:=a.clientFromToken(token)
iferr!=nil {
returnctx, grpc.Errorf(codes.Unauthenticated, "Unable to identifiy client with token `%s`", token)
}
// Client has been authenticated, that's enough to consume// Now check client is authorised to publishifa.SecurePublish&&strings.Contains(strings.ToLower(method), "publish") &&!client.acl.publish {
returnctx, grpc.Errorf(codes.PermissionDenied, "Client `%s` has no permission to publish", token)
}
returnctx, nil
}
The text was updated successfully, but these errors were encountered:
Am I interested in reviving this issue, but also introducing the ability to lock down consume/publish on a per-topic basis as well.
Potentially have some kind of config file that would have contain access rights for different roles clients? (being optional if you choose not to use this feature)
Two use cases identified
Authentication
As the number of consumers has grown & the ability to do so is not restricted we've been unable to keep track. When an issue arises or we have to coordinate changes (for example, as we've been making changes to the underlying nats streaming cluster) it's been helpful to chat with other teams/consumers.
An identifier could also be used in metrics (who's consuming/publishing the most) or logs (which client caused a repeatable server panic).
I played with 2 ideas for identifying a client
ACL
The main driver for authentication has been to implement ACL on the publishing side of things. We should be able to restrict who can publish back into the stream.
An example spike looks like...
The text was updated successfully, but these errors were encountered: