VictoriaMetrics / operator

Kubernetes operator for Victoria Metrics
Apache License 2.0
406 stars 142 forks source link

[BUG] Failing VMAuth/VMUser CR's after 0.42.0 Release - On Manually Created #962

Closed seanocca closed 1 month ago

seanocca commented 1 month ago

This bug has been an error since the 0.42.0 release. When you create a VMAuth and VMUser CR the operator fails to connect the managed secret to the deployment. The error is cannot create or update vmauth deploy: cannot update deployment for app: vmauth-main, err: Deployment.apps "vmauth-main" is invalid: spec.template.spec.containers[0].volumeMounts[1].name: Not found: "config"

The VMAuth CR creates the secret but the deployment searches for a configSecretRef value that does not exist.

This requires us to import and create our own secret with the potential to leak our username and password.

Why can we set the username, password, or passwordRef (with a password imported from another secret) on the VMUser CR, if those values don't build a secret that is to be used by the VMAuth deployment?

We have implemented the suggested work around by creating our own secret with the config.yaml file in the secret and changing the VMAuth configSecret setting to point to that. However the old method of the operator creating the secret and managing it is much more preferred. As it also won't require further config-reloader settings to be required.

Steps to reproduce: Operator Deploy method: VM Operator Helm Chart (0.31.1) into Kubernetes (1.28) VMAuth/VMUser Deployment Method: Manual CR's created and deployed

Haleygo commented 1 month ago

Hello @seanocca , I can't seem to reproduce it by creating vmauth like

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAuth
metadata:
  name: test
spec:
  extraArgs:
    discoverBackendIPs: "true"
    logInvalidAuthTokens: "true"
  image:
    tag: v1.101.0
  replicaCount: 1
  unauthorizedAccessConfig:
  - src_paths:
    - /insert/.*
    url_prefix:
    - http://vminsert:8480

Could you please provide an example here?

seanocca commented 1 month ago

Hi @Haleygo This is the config we are using to deploy the VMUser and VMAuth

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAuth
metadata:
  name: vmauth-main
spec:
  selectAllByDefault: true
  ingress:
    host: your.url.com    
  image:
    repository: victoriametrics/vmauth
    pullPolicy: IfNotPresent
    tag: v1.101.0
  replicaCount: 1
  resources:
    requests:
      cpu: "250m"
      memory: "350Mi"
    limits:
      cpu: "500m"
      memory: "850Mi"
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMUser
metadata:
  name: test-user
spec:
  username: "test-user"
  passwordRef:
    name: test-auth-secret
    key: password  
  targetRefs:
  - paths:
      - /api/v1/write
    static:
      url: http://vminsert:8480/insert/0/prometheus
Haleygo commented 1 month ago

@seanocca Did you set env VM_USECUSTOMCONFIGRELOADER = true inside vm-operator like https://github.com/VictoriaMetrics/operator/pull/964 describes?

seanocca commented 1 month ago

@Haleygo The config forVM_USECUSTOMCONFIGRELOADER is set to true in the operator. If we set this to false would the config that gets created by the operator (with values from VMAuth and VMuser) be setup and used correctly? Or does having this set to true mean the config should have been managed by the operator?

Haleygo commented 1 month ago

If we set this to false would the config that gets created by the operator (with values from VMAuth and VMuser) be setup and used correctly?

Yes. There was a bug on volumeMounts on customer config reloader and fixed in https://github.com/VictoriaMetrics/operator/pull/964, will be included in next release.

f41gh7 commented 1 month ago

Changes was included to v0.45.0 release.