This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.4.5. Configuring the Reporting Operator
The Reporting Operator is responsible for collecting data from Prometheus, storing the metrics in Presto, running report queries against Presto, and exposing their results via an HTTP API. Configuring the Reporting Operator is primarily done in your MeteringConfig
custom resource.
4.5.1. Securing a Prometheus connection 复制链接链接已复制到粘贴板!
When you install metering on OpenShift Container Platform, Prometheus is available at https://prometheus-k8s.openshift-monitoring.svc:9091/.
To secure the connection to Prometheus, the default metering installation uses the OpenShift Container Platform certificate authority (CA). If your Prometheus instance uses a different CA, you can inject the CA through a config map. You can also configure the Reporting Operator to use a specified bearer token to authenticate with Prometheus.
Procedure
Inject the CA that your Prometheus instance uses through a config map. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternatively, to use the system certificate authorities for publicly valid certificates, set both
useServiceAccountCA
andconfigMap.enabled
tofalse
.- Specify a bearer token to authenticate with Prometheus. For example:
4.5.2. Exposing the reporting API 复制链接链接已复制到粘贴板!
On OpenShift Container Platform the default metering installation automatically exposes a route, making the reporting API available. This provides the following features:
- Automatic DNS
- Automatic TLS based on the cluster CA
Also, the default installation makes it possible to use the OpenShift service for serving certificates to protect the reporting API with TLS. The OpenShift OAuth proxy is deployed as a sidecar container for the Reporting Operator, which protects the reporting API with authentication.
4.5.2.1. Using OpenShift Authentication 复制链接链接已复制到粘贴板!
By default, the reporting API is secured with TLS and authentication. This is done by configuring the Reporting Operator to deploy a pod containing both the Reporting Operator’s container, and a sidecar container running OpenShift auth-proxy.
To access the reporting API, the Metering Operator exposes a route. Once that route has been installed, you can run the following command to get the route’s hostname.
METERING_ROUTE_HOSTNAME=$(oc -n openshift-metering get routes metering -o json | jq -r '.status.ingress[].host')
$ METERING_ROUTE_HOSTNAME=$(oc -n openshift-metering get routes metering -o json | jq -r '.status.ingress[].host')
Next, set up authentication using either a service account token or basic authentication with a username and password.
4.5.2.1.1. Authenticate using a service account token 复制链接链接已复制到粘贴板!
With this method, you use the token in the Reporting Operator’s service account, and pass that bearer token to the Authorization header in the following command:
TOKEN=$(oc -n openshift-metering serviceaccounts get-token reporting-operator)
$ TOKEN=$(oc -n openshift-metering serviceaccounts get-token reporting-operator)
curl -H "Authorization: Bearer $TOKEN" -k "https://$METERING_ROUTE_HOSTNAME/api/v1/reports/get?name=[Report Name]&namespace=openshift-metering&format=[Format]"
Be sure to replace the name=[Report Name]
and format=[Format]
parameters in the URL above. The format
parameter can be json, csv, or tabular.
4.5.2.1.2. Authenticate using a username and password 复制链接链接已复制到粘贴板!
Metering supports configuring basic authentication using a username and password combination, which is specified in the contents of an htpasswd file. By default, a secret containing empty htpasswd data is created. You can, however, configure the reporting-operator.spec.authProxy.htpasswd.data
and reporting-operator.spec.authProxy.htpasswd.createSecret
keys to use this method.
Once you have specified the above in your MeteringConfig
resource, you can run the following command:
curl -u testuser:password123 -k "https://$METERING_ROUTE_HOSTNAME/api/v1/reports/get?name=[Report Name]&namespace=openshift-metering&format=[Format]"
$ curl -u testuser:password123 -k "https://$METERING_ROUTE_HOSTNAME/api/v1/reports/get?name=[Report Name]&namespace=openshift-metering&format=[Format]"
Be sure to replace testuser:password123
with a valid username and password combination.
4.5.2.2. Manually Configuring Authentication 复制链接链接已复制到粘贴板!
To manually configure, or disable OAuth in the Reporting Operator, you must set spec.tls.enabled: false
in your MeteringConfig
resource.
This also disables all TLS and authentication between the Reporting Operator, Presto, and Hive. You would need to manually configure these resources yourself.
Authentication can be enabled by configuring the following options. Enabling authentication configures the Reporting Operator pod to run the OpenShift auth-proxy as a sidecar container in the pod. This adjusts the ports so that the reporting API isn’t exposed directly, but instead is proxied to via the auth-proxy sidecar container.
-
reporting-operator.spec.authProxy.enabled
-
reporting-operator.spec.authProxy.cookie.createSecret
-
reporting-operator.spec.authProxy.cookie.seed
You need to set reporting-operator.spec.authProxy.enabled
and reporting-operator.spec.authProxy.cookie.createSecret
to true
and reporting-operator.spec.authProxy.cookie.seed
to a 32-character random string.
You can generate a 32-character random string using the following command.
openssl rand -base64 32 | head -c32; echo.
$ openssl rand -base64 32 | head -c32; echo.
4.5.2.2.1. Token authentication 复制链接链接已复制到粘贴板!
When the following options are set to true
, authentication using a bearer token is enabled for the reporting REST API. Bearer tokens can come from service accounts or users.
-
reporting-operator.spec.authProxy.subjectAccessReview.enabled
-
reporting-operator.spec.authProxy.delegateURLs.enabled
When authentication is enabled, the Bearer token used to query the reporting API of the user or service account must be granted access using one of the following roles:
- report-exporter
- reporting-admin
- reporting-viewer
- metering-admin
- metering-viewer
The Metering Operator is capable of creating role bindings for you, granting these permissions by specifying a list of subjects in the spec.permissions
section. For an example, see the following advanced-auth.yaml
example configuration.
Alternatively, you can use any role which has rules granting get
permissions to reports/export
. This means get
access to the export
sub-resource of the Report
resources in the namespace of the Reporting Operator. For example: admin
and cluster-admin
.
By default, the Reporting Operator and Metering Operator service accounts both have these permissions, and their tokens can be used for authentication.
For basic authentication you can supply a username and password in the reporting-operator.spec.authProxy.htpasswd.data
field. The username and password must be the same format as those found in an htpasswd file. When set, you can use HTTP basic authentication to provide your username and password that has a corresponding entry in the htpasswdData
contents.