Skip to content

JWT authentication causing "Epoch 0 terminated with an error" in Envoy #15084

Closed
@divya21raj

Description

@divya21raj

Bug description
I'm trying to implement service to service JWT authentication like something shown in this repo. While it's working fine with Auth0, I'm having trouble while setting it up with my company's authentication service. I made the service architecture by following this article, you can see my repository here.

This is the policy I'm applying ->

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  origins:
  - jwt:
      issuer: "My-Issuer"
      jwksUri: "http://10.0.75.1:8080/pub_key.json"
  principalBinding: USE_ORIGIN

I'm hosting the public key locally, you can find it here too.
If I hit the service with an invalid access key (say it's expired), I'm getting a 401 as expected, but a valid access key gives a
503: upstream connect error or disconnect/reset before headers. reset reason: connection failure

Upon checking the logs for the envoy proxy of the publisher pod, I can see this ->
Epoch 0 terminated with an error: signal: segmentation fault (core dumped)

This log message isn't there when working successfully with Auth0, so I think this might be a hint. But looking at the lines in the source code where this log message is present, I can't figure out much....

One reason I think this might occur is the different keys in access token I'm passing. The Auth0 access token has the following keys ->

{
  "iss": "https://xyz-sa.auth0.com/",
  "sub": "0BH7c261T8X0nt9b9B3UE4mP0L5O057V@clients",
  "aud": "https://sentiment-analysis.io/webapp",
  "iat": 1561353753,
  "exp": 1561440153,
  "azp": "0BH7c261T8X0nt9b9B3UE4mP0L5O057V",
  "gty": "client-credentials"
}

And my access token looks like this ->

{
  "http://www.xyz.com/identity/claims/tenancy/slug": "4d8ad062-7f6d-4b4d-9a64-f1c3627a97b4",
  "subtype": "app",
  "nbf": 1561353003,
  "exp": 1561354803,
  "iss": "xyz.com"
}

Anybody has any ideas, I've been stuck for quite some time now, any help will be appreciated..!

Affected product area (please put an X in all that apply)

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[x] Policies and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastrcture

Expected behavior
200 on valid Access Token

Steps to reproduce the bug
Sadly not possible, as the access token I'm using is private to my company :(
Version (include the output of istioctl version --remote and kubectl version)
version.BuildInfo{Version:"1.1.7", GitRevision:"eec7a74473deee98cad0a996f41a32a47dd453c2", User:"root", Host:"341b3bf0-76ac-11e9-b644-0a580a2c0404", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.6-6-geec7a74"}

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
Helm template, I followed this article.

Environment where bug was observed (cloud vendor, OS, etc)
Windows 10, running the cluster on Minikube.

Additionally, please consider attaching a [cluster state archive](http://istio.io/help/bugs/#generating-a-cluster-state-archive
istio-dump.tar.gz
) by attaching
the dump file to this issue.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions