Help: How do I limit the access to predefined users

[frossi85]

Hi,

I am new at Verdaccio. I used this to deploy Verdaccio in my Kubernetes cluster in Digital Ocean, but even after seen that has the htpasswd enabled everyone can add a user with npm adduser --registry {VERDACCIO_HOST}. Besides the max_users is there a way to limit users to be added without some admin add them to the htpasswd file?

I added two users then I checked the htpasswd file and I can only see the one which I think it was created during the installation. So I do not understand well the purpose of that file if everyone with the host can add himself as a publisher.

I did not find any useful info on how to admin users or limit user access. Could u help me with this?

Thanks a lot in advance.

[orefalo]

I used a custom values.yaml file as follows

1. go to https://hostingcanada.org/htpasswd-generator/

2. create yourself a login/password using MD5 (important)
   ie. test:$apr1$9snlk40p$ZxeHAQ7jsSt3qoRptjBh./

3. then in the values.yaml file, copy paste the value as follow. Note that you can add more than one entry.

htpasswd: |
  test:$apr1$9snlk40p$ZxeHAQ7jsSt3qoRptjBh./:autocreated 2019-07-06T11:54:15.003Z

4. start with:
   helm install verdaccio verdaccio/verdaccio --values values.yaml

[kav]

Does that work? I'm not seeing where that's consumed by the chart. Is this a missing feature or do I need to look closer?

[kav]

Looks like more folks are having trouble here verdaccio/verdaccio#1989 (comment). I'll take a look and add some notes here on a design. I'd like to avoid requiring a generated htpasswd file or placing cleartext passwords in values while supporting those option as well.

Here are the possibilities (brain dumping a bit):

1. An htpasswd entry in values as described above (maybe already implemented).

htpasswd: |
  test:$apr1$9snlk40p$ZxeHAQ7jsSt3qoRptjBh./:autocreated 2019-07-06T11:54:15.003Z

2. A htpasswdSecret property where the value is a secret containing the .htpasswd file

htpasswdSecret: htpasswrd-secret

assuming you also create

apiVersion: v1
kind: Secret
metadata:
  name: htpasswd
data:
  htpasswd: dGVzdDokYXByMSQ5c25sazQwcCRaeGVIQVE3anNTdDNxb1JwdGpCaC4vOmF1dG9jcmVhdGVkIDIwMTktMDctMDZUMTE6NTQ6MTUuMDAzWg==

3. A users array containing username and password properties

users:
- name: test
  password: YouBetterNotUsePassword123

alternatively, but strangely a rare pattern in kubernetes/helm

users:
- test: YouBetterNotUsePassword123

4. A usersSecret that contains similar

usersSecret: accounts-secret

which again assumes you create a secret as:

apiVersion: v1
kind: Secret
metadata:
  name: accounts-secret
data:
  test: WW91QmV0dGVyTm90VXNlUGFzc3dvcmQxMjM=

2 and 4 work better in GitOps flows so are likely what I'd use. I don't like sensitive info in my values but YMMV. 3 and 4 are obviously leaking less of the underlying abstraction vs 1 and 2 which are simpler for folks already up and running.

All four could easily be fairly trivially supported so I'm looking for feedback on design and naming mostly rather than a which one should we do, unless of course you really hate an option.

Anyone have thoughts on naming of properties (users vs perhaps accounts)?

[todpunk]

Accounts is more accurate, as it might be a team account or a system account or could be thought of as a "role" or some other principal.

The current implemented thing that I use in an install is having this (I generated the line for this comment, but there's a line for my one CI/CD account):

apiVersion: v1
kind: ConfigMap
metadata:
  name: verdaccio-htpasswd
  namespace: npm-registry
data:
  htpasswd: |
    test:$2y$10$dy8t/9PqrcY0nlprWvhgL.p3gp5u2q9Q3a1PnEsmTK7dDCtyK7ACe

Then in the chart values I have

persistence:
  enabled: true
  accessMode: ReadWriteOnce
  size: 200Gi
  volumes:
  - name: verdaccio-htpasswd-volume
    configMap:
      name: verdaccio-htpasswd
  mounts:
  - mountPath: /verdaccio/config/
    name: verdaccio-htpasswd-volume
    readOnly: true

configMap: |
  storage: /verdaccio/storage/data
  web:
    title: Verdaccio
  auth:
    htpasswd:
      file: /verdaccio/config/htpasswd
   ...

It might not be difficult to get that into the chart itself, but not strictly necessary either.

[johanhelsing-attensi]

Is there currently a way to store the password in a secret, and not in a configmap?

[todpunk]

Kubernetes allows you to mount a secret as a volume. Here's a nice explantion of how in tutorial form: https://www.jeffgeerling.com/blog/2019/mounting-kubernetes-secret-single-file-inside-pod

Verdaccio's chart is compatible with this k8s pattern since it would just be a volume/mount pair like my example.

[kav]

Sorry y'all I should have implemented this. Let me ask a mentee to take a stab at it as it's a great "improving your helm/kubernetes" fu exercise. Pinging @josephedward

[josephedward]

@kav will take a look but a bit distracted as you know, might be a while. Do you have some examples where an environment variable (|| default value...?) is passed with values.yaml to create a flat file with htpasswd? Could you make a JSON list of users that you stored in your account that was pulled to create the authorization file? Disclaimer - I know little about verdaccio, this chart, and I found D.O. k8s challenging compared to GKE.