Problem
gRPC unary handlers (GetSession, CreateSession, UpdateSession, DeleteSession, ListSessions, PushSessionMessage, etc.) have no RBAC authorization. The HTTP path has AuthorizeApi middleware that evaluates bindings and populates AuthResult, but there is no equivalent gRPC interceptor.
Any authenticated user can call gRPC unary methods with zero permission checks. The gRPC surface is currently protected by network isolation (cluster-internal only), but this is a defense-in-depth gap.
Root Cause
The upstream rh-trex-ai framework does not expose a RegisterPostAuthGRPCUnaryInterceptor hook. The existing RegisterPreAuthGRPCUnaryInterceptor runs before JWT validation, which is too early for RBAC evaluation.
Impact
- Severity: Critical (when gRPC is network-accessible)
- Current mitigation: gRPC port (9000) is cluster-internal only, no external Route/Ingress
- Affected handlers: All gRPC unary methods across sessions, projects, users, projectSettings, inbox plugins (~14 handlers)
Found By
Security council review (CISA + OWASP + BeyondCorp) — Finding 1 in PR #1660.
Problem
gRPC unary handlers (GetSession, CreateSession, UpdateSession, DeleteSession, ListSessions, PushSessionMessage, etc.) have no RBAC authorization. The HTTP path has
AuthorizeApimiddleware that evaluates bindings and populatesAuthResult, but there is no equivalent gRPC interceptor.Any authenticated user can call gRPC unary methods with zero permission checks. The gRPC surface is currently protected by network isolation (cluster-internal only), but this is a defense-in-depth gap.
Root Cause
The upstream
rh-trex-aiframework does not expose aRegisterPostAuthGRPCUnaryInterceptorhook. The existingRegisterPreAuthGRPCUnaryInterceptorruns before JWT validation, which is too early for RBAC evaluation.Impact
Found By
Security council review (CISA + OWASP + BeyondCorp) — Finding 1 in PR #1660.