Malformed bootstrap.creds string prevents Artifactory from starting #1891
Comments
|
Hi @keyboardsmash, Thank you for creating issue, but this is expected. Better way is to update password here |
|
Hello @oumkale, I don't agree. It took lots of effort to figure out that the problem with the join key was due to this. Please add a format check in the chart. |
|
hello @oumkale from a security standpoint its not that great to store a password in a helm chart in a high sec environment, this is the reason we use sealed secrets. |
|
Completely agree, we only just got round this weird error by thankfully finding this article But as @lunderhage says, there are many issues open and related to join key errors in the logs, when in fact they are caused usually by a problem during bootstrapping, suggesting this as expected behaviour makes little sense and doesn't seem like a good idea at all. |
BUG REPORT
Version of Helm and Kubernetes:
Which chart:
Which product license (Enterprise/Pro/oss):
JFrog support reference (if already raised with support team):
What happened:
While configuring Artifactory on our Openshift cluster using sealed secrets, I accidentally wrote the
bootstrap.credsstring aspasswordinstead ofadmin@127.0.0.1=password. This resulted in Artifactory not being able to start, micro services failing en masse:jfco,jfevt,jfmd,jfint(only present in 107.71.11),jfrtcould not join or access thejfroumicro service.Jfroucould not connect tojfacdue to it being unable to start caused by the malformed string. Jfrou output:[jfrou] Cluster join: Access Service ping failed, will retry. Error: cluster join: error from service registry on ping: url=http://localhost:8040/access/api/v1/system/ping, status code=404, body(100 first chars)='<!doctype html><html lang="en"><head><title>HTTP Status 404 – Not Found</title><style type="text/c'Not being overly familiar with the inner workings of the micro services, we first thought there was a problem with the join key since most services said they could not join. Finally we found the problem in the access service:
Log short:
jfac-log.log
What you expected to happen:
That the system should come up regardless of the string being malformed. Either by accepting a single value as password and defaulting the rest of the string to
admin@127.0.0.1=or throwing a visual warning on the login page stating that there is no valid local admin account. Regardless, Artifactory should still come up and allow users local or using other authentication providers to login and continue using the service. It should not be a showstopper in case someone later fails to rotate the credentials and updating or redeploying Artifactory. Doing so currently will at best leave Artifactory in a degraded state (multiple nodes) or worst case; totally down (single node).How to reproduce it (as minimally and precisely as possible):
Set a malformed string as
bootstrap.credsAnything else we need to know:
Pranav Hegde suggested we create an issue.
The text was updated successfully, but these errors were encountered: