This article discusses the scenario in which authentication is bypassed for gRPC in a cRPD environment.
Two cRPD instances were deployed in the same container, and when a gRPC connection was attempted from one cRPD to another, it was established with incorrect authentication or even without username/password credentials.
In the cRPD environment, we configured the root password and gRPC-related settings (see below for the configuration). Since SSL-based authentication is not configured and both containers are on the same host, it is expected that a gRPC connection to cRPD would only be established using the correct username and password. However, connections are being established even without authentication. There is an explicit command to disable authentication: set system services extension-service request-response grpc skip-authentication However, this command is not configured, so a connection should not be possible without proper authentication.
Config- root@cRPD > show configuration services { extension-service { request-response { grpc { clear-text { address 127.0.0.1; port 50051; } max-connections 3; } } } }
We observed a similar issue in the lab while running cRPD on the customer's version of Linux (Oracle 7.9). Even when providing an incorrect password, the gRPC connection is still established, and route updates are sent over gRPC.
[root@crr1 24.2R1.17]# python3 test_route_subscribe_api_v2.py -d 127.0.0.1 -p 50051 -u tester -pw test123 --print_routes --print_bootstrap [INFO] Connected to gRPC Server Resolved address: 127.0.0.1 Initialize response code: 0 status { message: "Operation completed successfully." } ... END_OF_RIBS received. Bootstrap time taken: 0.001878499984741211 Iterations: 1 Bootstrap updates: 4, deletes: 0 =======BOOTSTRAP END=========
With Incorrect Authentication:
[root@crr1 24.2R1.17]# python3 test_route_subscribe_api_v2.py -d 127.0.0.1 -p 50051 -u tester -pw test123 --print_routes --print_bootstrap [ERROR] gRPC Server Connection failed: Authentication failed for user Resolved address: 127.0.0.1 Initialize response code: 0 status { message: "Operation completed successfully." } ... END_OF_RIBS received. Bootstrap time taken: 0.0019199848175048828 Iterations: 1 Bootstrap updates: 4, deletes: 0 =======BOOTSTRAP END=========
Lab Configuration:
root@cRR1> show configuration system root-authentication { encrypted-password "$6$ZdhQ0$Z19rMo8TjyNTsR2HOCI4xd2KSx3HVniSx1vUdmvRHotxBJjz5korg4rmsdVFT3XJt8CR8bGUW49TREfkDy97g0"; ## SECRET-DATA } login { user tester { uid 2000; class super-user; authentication { encrypted-password "$6$Agvrk$7xSJgtejrjwd43r2Mht3/KdB1onnRkD6sXG0lcoF9CLLra22ECXABSb/e1vamG.Oq3507h06cFph.K1Q3NMF01"; ## SECRET-DATA } } } services { netconf { ssh; } ssh { root-login allow; } extension-service { request-response { grpc { clear-text { address 127.0.0.1; port 50051; } max-connections 3; } } traceoptions { file grpc_log; flag grpc; } } }
JET RPC is sent from the IRI client to cRPD, and RPC execution is successful even if authentication fails for internal clients. This behavior is expected. Trace Analysis: We see from the traces that JADE authentication failed:
Sep 22 18:33:49 grpcClientThread: Processing RPC /jnx.jet.authentication.Authentication/Login Sep 22 18:33:49 grpcClientThread: RPC was received on port 50051 Sep 22 18:33:51 parseMetadataAuthenticationResponse: Authentication failed for user ... Sep 22 18:33:51 JGrpcServerStart: Ipv4 address of connected socket is 127.0.0.1 Sep 22 18:33:51 JGrpcServerStart: Received call from IRI client ipv4:127.0.0.1:35996 ... Sep 22 18:33:51 CreateJapiChannel: GRPC Channel created Successfully
After the authentication failure, the gRPC channel is created successfully, indicating that RPC will be processed even if authentication fails for both UDS clients and IRI clients.