Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: errror message when using http urls for OIDC providers is missleading #1216

Open
hardillb opened this issue Jun 23, 2024 · 5 comments
Assignees
Labels
bug needs triage Waiting for discussion / prioritization by team
Milestone

Comments

@hardillb
Copy link

hardillb commented Jun 23, 2024

Steps to Reproduce

Setup up OIDC provider with a HTTP URL and try and use it to issue a new SSH certificate

e.g. follow these instructions (but do not enable HTTPS for Keycloak)

The error message on the line after this test for the URL not starting with https:// only mentions github/google not the real reason

if o.Provider != "google" && o.Provider != "github" && !strings.HasPrefix(o.Provider, "https://") {

Your Environment

  • OS - linux (Fedor and Ubuntu)
  • step CLI Version - Smallstep CLI/0.23.0 (linux/amd64), Release Date: 2022-11-12T00:00:59Z

Expected Behavior

The error message mention that the URL provided is not https

Actual Behavior

$ step ssh login --issuer=keycloak [email protected]
✔ Provisioner: keycloak (OIDC) [client: step-ca]
use a valid provider: google or github
error running: step oauth --oidc --bare --provider http://keycloak.k8s.loc/realms/xxxxx/.well-known/openid-configuration --client-id step-ca --client-secret 0OLuF5LOrP3dYQXzgxxxxxxxxxxxxxx --listen :10000: exit status 1

This error message is less than helpful, but a at least it gave me the command that failed...

$ step oauth --oidc --bare --provider http://keycloak.k8s.loc/realms/xxxxx/.well-known/openid-configuration --client-id step-ca --client-secret 0OLuF5LOrP3dYQXzgxxxxxxxxxxxxxx  --listen :10000
use a valid provider: google or github

Additional Context

Yes I know I can use smallstep ca to issue a cert for keycloak, but it was already up and running without when I ran the test and it was lucky that googling the error message took me to the code and I could understand what the error actually meant by reading the test that triggered it

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@hardillb hardillb added bug needs triage Waiting for discussion / prioritization by team labels Jun 23, 2024
@hardillb hardillb changed the title [Bug]: errror when using http urls for OIDC providers is missleading [Bug]: errror message when using http urls for OIDC providers is missleading Jun 23, 2024
@dopey dopey self-assigned this Jun 25, 2024
@hardillb
Copy link
Author

Just as a follow up I enabled HTTPS for keycloak using cert-manager the acme provider from the step-ca instance I have.

This lead to step-ca not starting because it claimed it didn't trust the certificate issued to keycloak...

How do I get a step-ca instance (running in docker) to trust certificates issued by it's self?

@hslatman
Copy link
Member

hslatman commented Jul 1, 2024

@hardillb maybe we can add the Step CA root to the trusted roots at the time of performing the OIDC requests. We do that in other places, but apparently not here. There might be a reason for that, but I don't know at this time.

At the moment you could add Step CA's root certificate to the Docker image by running step ca bootstrap ..., similar to what you would do on another client system.

The original issue is a valid concern, and will be picked up 🙂

@hardillb
Copy link
Author

hardillb commented Jul 1, 2024

I don't think running step ca bootstrap will work.

The $STEPPATH is already set to /home/step in the container so it would just put a copy of the root cert in the same place (/home/step/certs/root_ca.crt).

And adding --install won't help because the container user is step and there is no usable sudo binary in the container to update things as root.

Or have I missed something?

@hslatman
Copy link
Member

hslatman commented Jul 2, 2024

Or have I missed something?

No, I think you're right. I wasn't thinking clearly about it being in the Docker context; sorry 😞

My colleague @jdoss mentioned during triage that it can be done by having the Step CA root on the Docker host, and then mounting it in the Docker container in the right place at runtime.

We also discussed smallstep/certificates#1909, and we decided that we want the CA to trust itself by default, and that change will be made.

@hardillb
Copy link
Author

hardillb commented Jul 2, 2024

No problem, thanks for the update.

I'll try mounting the the root cert into the container on /usr/local/share/ca-certificates and see if that works in the mean time (but I think that still needs update-ca-certificates running as root to take effect)

I'll keep an eye on both issues.

@hslatman hslatman added this to the v0.27.3 milestone Jul 23, 2024
@hslatman hslatman modified the milestones: v0.27.4, v0.27.5 Sep 16, 2024
@hslatman hslatman modified the milestones: v0.27.5, v0.27.6 Oct 22, 2024
@hslatman hslatman modified the milestones: v0.27.6, v0.28.1 Oct 30, 2024
@hslatman hslatman modified the milestones: v0.28.1, v0.28.3 Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug needs triage Waiting for discussion / prioritization by team
Projects
None yet
Development

No branches or pull requests

3 participants