epinio: epinio user (log in on from dex) cant do 'epinio app exec APP-name'

Describe the bug It seems like users that login via dex. eg: epinio login --oidc <epinio-url> cant do shell to container.

To Reproduce Steps to reproduce the behavior, e.g.:

Install epinio version 1.5.2
login using dex user: user - admin@epinio.io/password
push an app (we use conda-app via paketo’s sample)
try container shell via: epinio app exec <app-name> . It will fail
Now, remove epinio session’s file in your current directory
login without dex. epinio login <epinio-url>
try epinio app exec <app-name> again… It will work

Expected behavior dex and local user should work the same.

Logs

╰─$ epinio app exec conda-app

🚢  Executing a shell
Namespace: workspace
Application: conda-app

❌  error getting a shell to application: error sending request: Get "https://epinio.internal.frxxdenv.xxx.com/wapi/v1/namespaces/workspace/applications/conda-app/exec?authtoken=eyJhbGciOiJSUzM4NCIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJlcGluaW8tc2VydmVyIiwiZXhwIjoxNjczNzk4OTc3LCJ1c2VyIjoiYWRtaW5AZXBpbmlvLmlvIn0.yd6Cdu8zRo_LpDNTgmAPhE9RtaoSo1kH0gnlJ_XsmUgAMYZqC7MZOU__ygHNidvO-WAxKUkfIv7UixTMXoc2fn2ME7CwKIB0ypkSRUVPN11XFceWQQqDD0C_6gEdXA2Agl4b0StEHMqjfySCDm-E7fFGLYvIbJNs2axJqwOiBatApv1PB-7maeImk1WUKJiXhZgEqXPRVW_amhRk1vj1DnCBC7ale1I3cs7oPGF-IO8Kv2fXm75h96Ml4JLatoRK3EmM4WT8UGSo_H538SVFRhEWw2s3jrnGVy86fvbO1f_i8UFO9dKXP-ahUSjWDtGRDANCgtBV4Am_ZvQroLh95Q": malformed HTTP response "\x00\x00\x1e\x04\x00\x00\x00\x00\x00\x00\x05\x00\x10\x00\x00\x00\x03\x00\x00\x00\xfa\x00\x06\x00\x10\x01@\x00\x01\x00\x00\x10\x00\x00\x04\x00\x10\x00\x00"

Cluster (please complete the following information):

Provider: K3D
Kubernetes Version: [e.g. 1.24]

Desktop/CLI (please complete the following information):

OS: [e.g. Linux, MacOS]
Epinio Version: 1.5.2

About this issue

Original URL
State: closed
Created a year ago
Comments: 19 (12 by maintainers)

Most upvoted comments

Fix via #2077

andreas-kupries on Feb 13, 2023

Yes. That PR lost (i.e. failed to save anymore) all certs which were trusted without user intervention.

andreas-kupries on Feb 13, 2023

Some progress today however. The issue is only in a difference of the login command between the versions. The version of the client used for the “action” (exec, or port-forward) then does not matter. Table:

Server	Login	Action	Exec	Port-Forward
1.6.2	1.6.2	1.6.2	💥	💥
1.6.2	1.6.2	1.5.1	💥	💥
1.6.2	1.5.1	1.6.2	🆗	🆗
1.6.2	1.5.1	1.5.1	🆗	🆗

Comparing the settings.yml files produced by the two versions shows that 1.5.1 saved some certs into the settings which 1.6.2 does not. Copying these certs into the 1.6.2 settings.yaml and the commands work. The error message from app exec looks to be simply what you get of the websocket stuff then the TLS handshake fails for a bad/missing cert.

I am now suspecting PR #1964 in 1.5.2. It is the one change in the login area from .1 to .2 and later.

andreas-kupries on Feb 13, 2023

@andreas-kupries

# Creation of cluster issuer integrated with Route53
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-epinio
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory 
    privateKeySecretRef:
      name: issuer-account-key
    solvers:
    - selector:
        dnsZones:
          - "DOMAIN.COM"
      dns01:
        route53:
          region: AWS_REGION
          role: arn:aws:iam::XXXXXXXXX:role/CertManager

riqueps on Jan 20, 2023

cc: @pedro-brito-ilia @riqueps

gitricko on Jan 16, 2023