-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MON-3802: implement cross-namespace rules for UWM #2307
base: master
Are you sure you want to change the base?
Conversation
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: simonpasquier The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
5db1763
to
3b2e644
Compare
/skip |
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
d319656
to
22bb813
Compare
current status:
|
As mentioned in the sync earlier, I would like to make sure we make it very clear to the user what we mean by |
f9d4f45
to
5b874d1
Compare
summarizing offline discussions about the console issue The problem is that cross-namespace rules won't be displayed in the developer console. As an example, I've deployed a cross-namespace rule ( It is visible in the admin console though: In terms of user experience, it is less than ideal since a user with only access to the The reason behind the issue is that the console uses the Possible options being discussed:
|
/hold |
I tested this with openshift/prom-label-proxy#369 and it's almost working. When clicking on the alert link to open the PromQL expression in the metrics dashboard, prom-label-proxy replies with a 400 status code and |
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.17.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
1051350
to
77b2f1b
Compare
/hold cancel |
/retest-required |
1 similar comment
/retest-required |
/skip |
This change introduces a way to deploy user-defined rules which are not scoped to their namespace of origin. To enable the feature, a user-defined monitoring admin needs to configure at least one namespace in the UWM ConfigMap: ``` kind: ConfigMap apiVersion: v1 metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: |- namespacesWithoutLabelEnforcement: [ user-monitoring-shared ] ``` For all `PrometheusRule` objects defined in the `user-monitoring-shared` namespace, Prometheus and Thanos Ruler evaluate the PromQL expressions without enforcing the namespace label of origin. It makes it possible to have generic rules that get applied to all (or a subset of) the user projects instead of having individual rule objects in each user project. The rules can also query for platform namespaces only. The capability is enabled by default but a cluster admin can decide to disable it in the CMO ConfigMap: ``` kind: ConfigMap apiVersion: v1 metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |- userWorkloadEnabled: true userWorkload: rulesWithoutLabelEnforcementAllowed: false ``` For example, a user-defined monitoring admin can create a single rule that fires when a user namespace doesn't enforce the Restricted pod security policy: ``` apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: security namespace: user-monitoring-shared spec: groups: - name: pod-security-policy rules: - alert: "NamespaceNotEnforcingRestrictedPolicy" expr: kube_namespace_labels{namespace!~"(openshift|kube).*|default",label_pod_security_kubernetes_io_enforce!="restricted"} for: 5m annotations: summary: "Restricted policy not enforced" description: "Namespace {{ $labels.namespace }} doesn't enforce the Restricted pod security policy." labels: severity: warning ``` Signed-off-by: Simon Pasquier <spasquie@redhat.com>
@simonpasquier: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
/assign @machine424 |
PR tested with cluster-bot, other user-defined namespace could trigger the alert in |
@simonpasquier: This pull request references MON-3802 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.18.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
Thanks for the testing @Tai-RedHat! I don't see a strong reason to prevent this situation (and it would be quite hard to detect). But it would be good to mention in the docs. |
This change introduces a way to deploy user-defined rules which are not
scoped to their namespace of origin.
To enable the feature, a user-defined monitoring admin needs to
configure at least one namespace in the UWM ConfigMap:
For all
PrometheusRule
objects defined in theuser-monitoring-shared
namespace, Prometheus and Thanos Ruler evaluate the PromQL expressions
without enforcing the namespace label of origin. It makes it possible to
have generic rules that get applied to all (or a subset of) the user
projects instead of having individual rule objects in each user project.
The capability is enabled by default but a cluster admin can decide to
disable it in the CMO ConfigMap:
For example, a user-defined admin can create a single rule that fires
when a user namespace doesn't enforce the Restricted pod security
policy.