POSTGRES_PASSWORD in Database and Core secrets being stored in plaintext rather than b64
stevenbales1 opened this issue · 5 comments
database:
type: internal
internal:
password: "blablablablablablalbabla"
Gets stored in the Kubernetes secret unencoded:
Data
POSTGRES_PASSWORD: 18 bytes
user@ssh:~$ kubectl get secret harbor-database -n harbor -o yaml
apiVersion: v1
data:
POSTGRES_PASSWORD: blablablablablablalbabla
kind: Secret
metadata:
annotations:
meta.helm.sh/release-name: harbor
meta.helm.sh/release-namespace: harbor
labels:
app: harbor
app.kubernetes.io/managed-by: Helm
chart: harbor
heritage: Helm
release: harbor
name: harbor-database
namespace: harbor
type: Opaque
This causes Harbor to crash, because it can't connect to the database until I manually b64 encode the password and store it in the secrets.
This is certainly no help, but after frustratedly struggling with this and related issues around the management of passwords, I opted for an external database managed by the Postgres Operator. I literally only just deployed it a couple hours ago, but I was satisfied to find that it can automatically create and manage credential secrets that just-so-happen to use the key password, and thus be directly compatible with this Helm chart. It also has the advantage of offering more flexibility for HA.
This certainly needs to be worked out so the Helm chart can operate as it promises, but this really hasn't been a bad compromise--at least for my needs and environment.
Whoever ends up looking into this, I'd also like to call attention to a particular incident of poor template variable naming that implies base64 is a mechanism for encryption.
We also have faced this issue - any news on a fix? to work around it we have added the b64 versions of the passwords to our values.yaml.... and it works :(
Facing the same issue after upgrading from v1.13.1...
The issue resides in two secrets:
secret/harbor-database->POSTGRES_PASSWORDsecret/harbor-core->POSTGRESQL_PASSWORD
a workaround is to...
- start the helm upgrade
- manually base64-encode the values of the two secrets shown above
- depending on the state of the upgrade one also quite likely needs to
- restart the
statefulset/harbor-database kubectl rollout restart deployment/harbor-core
- restart the
- observe the helm upgrade, which should succeed using a sufficiently high timeout (e.g., 10m)
We're getting hit by this as well. It's a little bit confusing as to why. After a bit of experimentation, deleting the secrets (and disabled the migrate hook) created the secrets correctly. So it seems that if the secret already exists in the cluster, it gets overwritten by the non-base64-encoded version upon upgrade.
I think the source of trouble is here
harbor-helm/templates/_helpers.tpl
Line 101 in 54979d8