The `VMAuth` CRD provides mechanism for exposing application with authorization to outside world or to other applications inside kubernetes cluster.
For first case, user can configure `ingress` setting at `VMAuth` CRD. For second one, operator will create secret with `username` and `password` at `VMUser` CRD name.
So it will be possible to access these credentials from any application by targeting corresponding kubernetes secret.
## Specification
You can see the full actual specification of the `VMAuth` resource in
the **[API docs -> VMAuth](../api.md#vmauth)**.
If you can't find necessary field in the specification of the custom resource,
see [Extra arguments section](./README.md#extra-arguments).
Also, you can check out the [examples](#examples) section.
## Users
The CRD specifies which `VMUser`s should be covered by the deployed `VMAuth` instances based on label selection.
The Operator then generates a configuration based on the included `VMUser`s and updates the `Configmaps` containing
the configuration. It continuously does so for all changes that are made to `VMUser`s or to the `VMAuth` resource itself.
[VMUser](./vmrule.md) objects generate part of `VMAuth` configuration.
For filtering users `VMAuth` uses selectors `userNamespaceSelector` and `userSelector`.
It allows configuring rules access control across namespaces and different environments.
Specification of selectors you can see in [this doc](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#labelselector-v1-meta).
In addition to the above selectors, the filtering of objects in a cluster is affected by the field `selectAllByDefault` of `VMAuth` spec and environment variable `WATCH_NAMESPACE` for operator.
Following rules are applied:
- If `userNamespaceSelector` and `userSelector` both undefined, then by default select nothing. With option set - `spec.selectAllByDefault: true`, select all vmusers.
- If `userNamespaceSelector` defined, `userSelector` undefined, then all vmusers are matching at namespaces for given `userNamespaceSelector`.
- If `userNamespaceSelector` undefined, `userSelector` defined, then all vmusers at `VMAgent`'s namespaces are matching for given `userSelector`.
- If `userNamespaceSelector` and `userSelector` both defined, then only vmusers at namespaces matched `userNamespaceSelector` for given `userSelector` are matching.
from [VictoriaMetrics Enterprise](https://docs.victoriametrics.com/enterprise.html#victoriametrics-enterprise).
For using Enterprise version of [vmauth](https://docs.victoriametrics.com/vmauth.html)
you need to change version of `vmauth` to version with `-enterprise` suffix using [Version management](#version-management).
All the enterprise apps require `-eula` command-line flag to be passed to them.
This flag acknowledges that your usage fits one of the cases listed on [this page](https://docs.victoriametrics.com/enterprise.html#victoriametrics-enterprise).
So you can use [extraArgs](./README.md#extra-arguments) for passing this flag to `VMAuth`:
### IP Filters
After that you can use [IP filters for `VMUser`](./vmuser.md#enterprise-features)
and field `ip_filters` for `VMAuth`.
Here are complete example with described above:
```yaml
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAuth
metadata:
name: vmauth-ent-example
spec:
# enabling enterprise features
image:
# enterprise version of vmauth
tag: v1.93.5-enterprise
extraArgs:
# should be true and means that you have the legal right to run a vmauth enterprise
# that can either be a signed contract or an email with confirmation to run the service in a trial period
# https://victoriametrics.com/legal/esa/
eula: true
# using enterprise features: ip filters for vmauth
# more details about ip filters you can read in https://docs.victoriametrics.com/vmauth.html#ip-filters
ip_filters:
allow_list:
- 10.0.0.0/24
- 1.2.3.4
deny_list:
- 5.6.7.8
# allow read vmsingle metrics without authorization for users from internal network