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

Registry Credentials htpasswdString and existingSecret do not work as expected #1830

Open
Nathan-Nesbitt opened this issue Sep 22, 2024 · 4 comments
Assignees

Comments

@Nathan-Nesbitt
Copy link

Nathan-Nesbitt commented Sep 22, 2024

This is the original issue: goharbor/harbor#20822 (comment)

I investigated further, looks that the issue is in relation to the values.yaml

credentials:
    username: "harbor_registry_user"
    password: "harbor_registry_password"
    # If using existingSecret, the key must be REGISTRY_PASSWD and REGISTRY_HTPASSWD
    existingSecret: ""
    # Login and password in htpasswd string format. Excludes `registry.credentials.username`  and `registry.credentials.password`. May come in handy when integrating with tools like argocd or flux. This allows the same line to be generated each time the template is rendered, instead of the `htpasswd` function from helm, which generates different lines each time because of the salt.
    # htpasswdString: $apr1$XLefHzeG$Xl4.s00sMSCCcMyJljSZb0 # example string
    htpasswdString: ""

If you use the username and password values, it will work as expected. But if you try to use the htpasswdString or existingSecret, it does not work. We do see the error from the previously defined bug.

To test the existing secret we set it to an existing secret in the namespace, reference it in the yaml, then fill in both the username and password values in the secret. We also check by putting in the htpasswdString into the secret to test if that works.

It could be a misunderstanding on how there are supposed to work, but as far as I can tell the secret is configured properly.

Any information on the proper setup / potential causes of this would be greatly appreciated :)

@Vad1mo
Copy link
Member

Vad1mo commented Sep 27, 2024

this is a "common"/"known" bug, I mentioned that a few times. There was also a comment in the yaml, (apparently its gone)

if htpasswdString is set, you also need to set username and password , with matching username and password. because username and password are used on the sender side (in harbor-core) whereas htpasswdString is used on registry.

@Nathan-Nesbitt
Copy link
Author

this is a "common"/"known" bug, I mentioned that a few times. There was also a comment in the yaml, (apparently its gone)

if htpasswdString is set, you also need to set username and password , with matching username and password. because username and password are used on the sender side (in harbor-core) whereas htpasswdString is used on registry.

Thanks for letting me know, so does this apply to the secret as well? So you would need

  • username
  • password
  • htpasswdString

All defined in the secret?

Because I've found that even when we set all 3 within the secret, it's causing an issue.

@Vad1mo
Copy link
Member

Vad1mo commented Sep 28, 2024

I would say so, but it seems doubtable made a different experience. Try to render the manifests locally and see if you get the matching username password taken from your secrets

@Nathan-Nesbitt
Copy link
Author

@Vad1mo how would we check the username/password/htpasswdString that is pulled into the application? Is there a way to have it log environment variables on run for each and dump the variables where they are being used?

We have these two scenarios:

  1. (Works) Username + password directly in the values.yaml
  2. (Doesn't work) Username + password stored in a secret, secret specified in the values.yaml

So I'm thinking it could be:

  1. The secret isn't formatted correctly (key names aren't as expected)
  2. The value for specifying the secret in the values.yaml should be different

Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants