- Exception message and full stack trace:
{
"headers": {
"normalizedNames": {},
"lazyUpdate": null
},
"status": 401,
"statusText": "OK",
"url": "https://{webGateway-URL}/api/identity/users/lookup/roles",
"ok": false,
"name": "HttpErrorResponse",
"message": "Http failure response for https://{webGateway-URL}/api/identity/users/lookup/roles: 401 OK",
"error": null
}
- Steps to reproduce the issue:
We have deployed a newly generated microservices solution using .NET and Angular as our frontend. All microservices under infrastructure (WebGateway, Saas, Language, AuthServer, Administration, etc) are deployed on an AKS cluster, each one with their own deployment, service and configmap. The only ingress created are for WebGateway and AuthServer. WebGateway communicates with all services using internal communication between services and don't use Ingresses, since all other microservices don't have an Ingress. We are doing this to avoid unneccesary exposure of our microservices. The issue is that as seen above, we can't correctly authenticate with each endpoint through WebGateway. We found that the call https://{webGateway-URL}/api/abp/application-configuration returns {"isAuthenticated":false,"id":null,"tenantId":null,"impersonatorUserId":null,"impersonatorTenantId":null,"impersonatorUserName":null,"impersonatorTenantName":null,"userName":null,"name":null,"surName":null,"email":null,"emailVerified":false,"phoneNumber":null,"phoneNumberVerified":false,"roles":[],"sessionId":null}. If we make our Web Gateway endpoint use the external Ingress URL we can authenticate successfully, but we want to avoid exposing microservice if it's not strictly necessary. We can guess that there are some information being lost when communicating internally, maybe some headers, as we are still debugging the issue. Communication between services is done using HTTP and not HTTPS.
My questions are: what is the best practice for communication between microservices in a Kubernetes cluster? should be strictly done through external URLs with Ingress or this can be done using services? How should we configure services for this to work correctly?
Thank you in advance. Best regards, Gaston Gallo
1 Answer(s)
-
0
In ABP microservice solutions deployed on Kubernetes, it is best practice for internal service-to-service communication to use Kubernetes internal DNS/service names (e.g., http://identity-service:port) rather than exposing every microservice via Ingress. Only the gateway(s) and AuthServer should be exposed externally.
For authentication to work correctly through the WebGateway, ensure the following:
- The WebGateway must forward the Authorization header and any relevant cookies from the client to the downstream services.
- All internal service URLs (RemoteServices:...:BaseUrl in appsettings) should use the internal Kubernetes service DNS names, not external URLs.
- The AuthServer's Authority URL must be consistent and reachable from all services (use the public AuthServer URL, even for internal calls, so tokens validate correctly).
- If you are using HTTP (not HTTPS) for internal calls, set RequireHttpsMetadata to false in your AuthServer and client configurations.
- If you use cookies for authentication, ensure SameSite and domain settings allow cookies to be sent between your gateway and frontend.
You do NOT need to expose all microservices via Ingress. Internal Kubernetes services are sufficient and recommended for security.
If authentication fails only for internal calls, double-check that:
- The Authorization header is not stripped or lost by the gateway or by any proxy/middleware.
- The WebGateway is configured to use the correct AuthServer Authority and that all microservices trust the same issuer.
Example configuration for internal service communication:
"RemoteServices": { "Identity": { "BaseUrl": "http://identity-service" // Kubernetes service name } }, "AuthServer": { "Authority": "https://authserver.yourdomain.com", // Public URL, even for internal calls "RequireHttpsMetadata": false }- For more details, see the official ABP microservice sample and deployment documentation.
Sources:
- ABP Microservice Demo - Authentication Gateway Example
- ABP Support: Kubernetes internal service authentication issues
- ABP Support: OpenId Connect issuer mismatch in K8s
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
