Right now I think most clients are falling into the port-forwarding / token minting path [1]
This is convenient for local development, but I don't think it should be the default authentication mode. We shouldn't assume that a user or service who is interacting with the Substrate API has any particular permissions on the Kubernetes cluster where Substrate is installed.
-
We should migrate all integration / e2e tests so that the calling code gets a JWT (or client certificate) that will work against the Substrate API from the execution environment. This could be a Kubernetes JWT with the correct audience for connecting to Substrate (via projected volume) if the calling code runs inside a pod. Or if the calling code is running inside of Github actions, there's a Github-issued JWT we can use.
-
We should document what you should be doing in common scenarios:
a) You are authenticating to the Substrate API from a service running inside a pod in a Kubernetes cluster (same cluster or different cluster). Configure Substrate so that it trusts JWTs issued by that cluster.
b) You are authenticating to the Substrate API as a human running kubectl ate. Set the --endpoint flag to aim at your Substrate install, and tell us how to invoke a command that will return a JWT (like how gcloud is integrated into kubectl) (this isn't built yet)
[1]
|
func bearerTokenDialOption(ctx context.Context, clientset *kubernetes.Clientset, tokenFile string) (grpc.DialOption, error) { |
Right now I think most clients are falling into the port-forwarding / token minting path [1]
This is convenient for local development, but I don't think it should be the default authentication mode. We shouldn't assume that a user or service who is interacting with the Substrate API has any particular permissions on the Kubernetes cluster where Substrate is installed.
We should migrate all integration / e2e tests so that the calling code gets a JWT (or client certificate) that will work against the Substrate API from the execution environment. This could be a Kubernetes JWT with the correct audience for connecting to Substrate (via projected volume) if the calling code runs inside a pod. Or if the calling code is running inside of Github actions, there's a Github-issued JWT we can use.
We should document what you should be doing in common scenarios:
a) You are authenticating to the Substrate API from a service running inside a pod in a Kubernetes cluster (same cluster or different cluster). Configure Substrate so that it trusts JWTs issued by that cluster.
b) You are authenticating to the Substrate API as a human running
kubectl ate. Set the--endpointflag to aim at your Substrate install, and tell us how to invoke a command that will return a JWT (like how gcloud is integrated into kubectl) (this isn't built yet)[1]
substrate/internal/ateclient/builder.go
Line 241 in 1ec75f9