search

jfrog / charts

JFrog official Helm Charts
https://jfrog.com/integration/helm-repository/
Apache License 2.0
255 stars 444 forks source link

Malformed bootstrap.creds string prevents Artifactory from starting #1891

Open keyboardsmash opened 3 months ago

keyboardsmash commented 3 months ago

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.creds string as password instead of admin@127.0.0.1=password. This resulted in Artifactory not being able to start, micro services failing en masse:

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: 

Error creating bean with name 'accessServerBootstrapImpl': Invocation of init method failed; nested exception is
 java.lang.IllegalArgumentException: Illegal credentials file - each line is expected to be in the format: user=pass

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.creds

Anything else we need to know: Pranav Hegde suggested we create an issue.

oumkale commented 3 months ago

Hi @keyboardsmash,

Thank you for creating issue, but this is expected. Better way is to update password here

lunderhage commented 3 months ago

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.

keyboardsmash commented 3 months ago

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.

reespozzi commented 3 weeks ago

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. +1 for the suggestion of this at the very least 

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.