Not able to authenticate after changing password

[guga-kudos]

Hey Guys, I don't know If I am doing something wrong!

I am installing the chart in a Kubernetes Cluster using the following command:

helm install mygraph RELEASE_URL --set core.standalone=true --set acceptLicenseAgreement=yes --set neo4jPassword=mySecretPassword

The deploy goes well and I can see the following message:

Changed password for user 'neo4j'.
Remote interface available at http://graphdb-neo4j-core-0.graphdb-neo4j.default.svc.cluster.local:7474

But then when we try to authenticate to db in our node.js service using user=neo4j and password=mySecretPassword we see the following message being returning by db:

Failed authentication attempt for 'neo4j' from 100.101.66.28

Also I have also trying doing a curl inside the neo4j container:

curl  http://neo4j:mySecretPassword@graphdb-neo4j-core-0.graphdb-neo4j.default.svc.cluster.local:7474/user/neo4j
{
  "errors" : [ {
    "code" : "Neo.ClientError.Security.Unauthorized",
    "message" : "Invalid username or password."
  } ]

Am I doing something wrong ?

PS. When I set authEnabled: false in the chart, everything works as expected :)

[moxious]

I'm not sure what's happening here because this bit is tested, and I can't reproduce.

Could you paste the exact command you're using to connect using this password, and what it's result is? Can you verify that the secret was installed in kubernetes, and that it's base64 decoded value is mySecretPassword?

A final thing to try is the default neo4j/neo4j. If the container failed to set your desired password (for some reason, which I doubt) then the password would be neo4j.

[moxious]

Any update here?

[guga-kudos]

Hey @moxious , thanks for your quick response and sorry for my late one.

So I investigated a little bit more and it seems to be related to persistent volumes. If I install the chart once, delete it, and install it again with a different password it will keep the first password stored in the volume.

I don't know if that is an issue, but it might get people confused.

Here is what a I did to reproduce:
(make sure to clean up all the persistent volumes and claims using kubectl, or install chart with a different name)

1. Install the chart for the first time:

helm install graphdb RELEASE_URL --set core.standalone=true --set acceptLicenseAgreement=yes --set neo4jPassword=pass1

2. Run inside the cluster:

# this should work
curl http://neo4j:pass1@graphdb-neo4j-core-0.graphdb-neo4j.default.svc.cluster.local:7474/user/neo4j

3. Delete chart:

helm delete graphdb --purge

4. Install it again with different password:

helm install graphdb RELEASE_URL --set core.standalone=true --set acceptLicenseAgreement=yes --set neo4jPassword=pass2

5. Run inside the cluster:

# this should not work
curl http://neo4j:pass2@graphdb-neo4j-core-0.graphdb-neo4j.default.svc.cluster.local:7474/user/neo4j

# this should work
curl http://neo4j:pass1@graphdb-neo4j-core-0.graphdb-neo4j.default.svc.cluster.local:7474/user/neo4j

[moxious]

Yes, this makes sense. When you set a password in neo4j 4.0+, it writes something to the system database. If you retain disk images between launches, then when your new database starts up, it will have the state on disk of the old system database, which of course has the old password.

This can be avoided several ways:

• When redeploying, use a different name
• Prior to redeploying, delete the PVCs associated with the old deploy
• Prior to redeploying, use other tooling to delete the /data/databases folders in the PVC mount point.

Unfortunately, as your'e describing this situation, it's working as intended. Helm doesn't auto-delete the PVCs associated with the install when you delete -- because the purpose of PVCs is to retain the data.

[guga-kudos]

@moxious, yes indeed!

Sorry, I guess it was misinformation from my end.

But it is a good headsup if anyone stubble upon this in the future :)

Thanks a lot for your help