-
Notifications
You must be signed in to change notification settings - Fork 88
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
feat: support secrets in scrape authorization #776
Conversation
d64dac7
to
cdbf808
Compare
930fba0
to
057922a
Compare
7f3cf8b
to
0120bb6
Compare
51538a8
to
5afff72
Compare
cbd0401
to
45a47fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Epic work!
LGTM, modulo small comments (some of them non-blocking when marked so). Thanks!
During my testing I noticed we could improve error handling for permissions on our Prom fork--added issue for that, but the consequences are not as bad as I thought. 💪🏽
e2e/authorization_test.go
Outdated
t.Run("patch-example-app-args", testPatchExampleAppArgs(ctx, kubeClient, []string{ | ||
"--tls-create-self-signed=true", | ||
})) | ||
authorizationClusterPodMonitoringTest(ctx, t, kubeClient, opClient, "tls", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit(non-blocking): There might be opportunity to make those table tests at some point: TestTLSPodMonitoring
and TestTLSClusterPodMonitoring
is only different by one thing - first is invoking authorizationClusterPodMonitoringTest
second authorizationPodMonitoringTest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to other tests for diff security types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another argument for table test is authorizationPodMonitoringTest (and cluster one) has a few arguments where you really have understand order and meaning of them. Table test would allow describing scenarios in explicit struct perhaps.
Proposed adding example #916 |
Some decision rationales: * Only ClusterSecretKeySelector for consistency and explicitness. We could rename it to SecretKeySelector I guess. * Credentials and others etc are optional for compatibility AND name is similar to e.g. secretKeyRef in https://pkg.go.dev/k8s.io/api/core/v1#EnvVarSource It feels cleaner this way and allows extensions if needed (e.g. credentials from some different secret provider). It could be *SecretKeyRef or *Ref or *SecretRef suffix but chosen something that reflects it's not a string, but also not too verbose. * Flattened the structure, make it a pointer, for simplicity. * Detached low level types from scrape in comments (it's generic HTTP) * One method for accessing things (and adding used secrets) for smaller boilerplate --------- Signed-off-by: bwplotka <bwplotka@google.com>
45a47fd
to
190c580
Compare
190c580
to
7df84e1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! 💪🏽 Let's go!
Thrilled about the new feature! Could you possibly share when it's expected to be available on GKE? Much appreciated! |
The feature is already available on the GKE rapid release channel 1.29.3-gke.1113000 and above. We expect to port this change to the regular release channel sometime before the end of Q2. For an example configuration, see: https://github.com/GoogleCloudPlatform/prometheus-engine/blob/main/examples/instrumentation/go-synthetic/go-synthetic-basic-auth.yaml For full usage, see: https://github.com/GoogleCloudPlatform/prometheus-engine/blob/main/doc/api.md Feel free to report any issues you see as a new bug on GitHub. Thanks for the interest! |
Thanks for the quick reply. I've successfully upgraded to 1.29.3-gke.1282000. Unfortunately, I'm having an issue with namespaces:
If I omit the apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
name: meilisearch
namespace: ecommerce
labels:
app.kubernetes.io/name: meilisearch
app.kubernetes.io/instance: meilisearch
app.kubernetes.io/version: "v1.7.0"
app.kubernetes.io/component: search-engine
app.kubernetes.io/part-of: meilisearch
spec:
selector:
matchLabels:
app.kubernetes.io/name: meilisearch
app.kubernetes.io/instance: meilisearch
endpoints:
- port: http
path: /metrics
interval: 1m
timeout: 10s
authorization:
type: Bearer
credentials:
secret:
name: meilisearch-master-key
key: MEILI_MASTER_KEY I've also attempted with
I guess this is related to #789 |
Fixes the issue shared through [1]. The current implementation only supports a PodMonitoring selecting a Secret from the `default` namespace. The existing E2E test cases were using a Secret deployed inside the `default` namespace therefore not covering this "edge" case [2]. Since the PodMonitoring CRD does not support selecting a Secret from another namespace [3], existing unit tests covering such scenario were removed. [1]: GoogleCloudPlatform#776 (comment) [2]: https://github.com/GoogleCloudPlatform/prometheus-engine/blob/f21c2ba4c0a9c3108209c1e59ec75d52e388235e/e2e/authorization_test.go#L96-L177 [3]: GoogleCloudPlatform@99444af Signed-off-by: Florian Daguin <git@fdaguin.dev>
Fixes the issue shared through [1]. The current implementation only supports a PodMonitoring selecting a Secret from the `default` namespace. The existing E2E test cases were using a Secret deployed inside the `default` namespace therefore not covering this "edge" case [2]. Since the PodMonitoring CRD does not support selecting a Secret from another namespace [3], existing unit tests covering such scenario were removed. [1]: #776 (comment) [2]: https://github.com/GoogleCloudPlatform/prometheus-engine/blob/f21c2ba4c0a9c3108209c1e59ec75d52e388235e/e2e/authorization_test.go#L96-L177 [3]: 99444af Signed-off-by: Florian Daguin <git@fdaguin.dev>
Fixes the issue shared through [1]. The current implementation only supports a PodMonitoring selecting a Secret from the `default` namespace. The existing E2E test cases were using a Secret deployed inside the `default` namespace therefore not covering this "edge" case [2]. Since the PodMonitoring CRD does not support selecting a Secret from another namespace [3], existing unit tests covering such scenario were removed. [1]: #776 (comment) [2]: https://github.com/GoogleCloudPlatform/prometheus-engine/blob/f21c2ba4c0a9c3108209c1e59ec75d52e388235e/e2e/authorization_test.go#L96-L177 [3]: 99444af Signed-off-by: Florian Daguin <git@fdaguin.dev>
Fixes the issue shared through [1]. The current implementation only supports a PodMonitoring selecting a Secret from the `default` namespace. The existing E2E test cases were using a Secret deployed inside the `default` namespace therefore not covering this "edge" case [2]. Since the PodMonitoring CRD does not support selecting a Secret from another namespace [3], existing unit tests covering such scenario were removed. [1]: #776 (comment) [2]: https://github.com/GoogleCloudPlatform/prometheus-engine/blob/f21c2ba4c0a9c3108209c1e59ec75d52e388235e/e2e/authorization_test.go#L96-L177 [3]: 99444af Signed-off-by: Florian Daguin <git@fdaguin.dev>
The fix is available in version: GKE 1.30: 1.30.2-gke.1054000 or later. And will be available in versions: GKE 1.29: 1.29.6-gke.1150000 or later. Please allow 2-3 weeks for these versions to get rolled out. Thanks! |
Hi, on 1.29.6-gke.1254000 I am still experiencing the same issue. Can you confirm the release schedule? |
Hi, we ended up doing additional security patch releases. 0.12 as shown in the releases page is available on the following GKE minor versions:
These are the corresponding available versions on the GKE rapid release channel:
Please create a new issue if you're having still problems since messages here could easily get lost! Thanks! |
Fixes #450 and #241.
This PR adds the following types to
PodMonitoring
/ClusterPodMonitoring
'sScrapeEndpoint
:scrapeEndpoint.tls.ca
scrapeEndpoint.tls.cert
scrapeEndpoint.tls.key
scrapeEndpoint.oauth2.clientSecret
scrapeEndpoint.auth.credentials
scrapeEndpoint.basicAuth.password
These are all the same object pointing to a Kubernetes Secret with these fields: