-
Notifications
You must be signed in to change notification settings - Fork 54
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
No matching policies (Restricted Environment) #681
Comments
This bug is a blocker for us. |
Same here |
@gustavoromerobenitez You shouldn't be concerned about these TrustRoot errors (although I am gonna check if I can reproduce them). Those are not related here. Could you try using using this value for authorities ?
If you want the policy controller to ignore not matching policies, you could also configure at controller level by running the following command:
Anyway I'll give it a try on my own cluster to verify the parameter disable-tuf is not causing any issue here. |
Thanks @hectorj2f, I will try those options and post the results here. How can I tell which policies have been loaded by the controller, and which policies the image path is being checked against? Thank you |
@gustavoromerobenitez There is a configMap config-image-policies that shows the loaded images ? The logs show how many policies (a counter) are matching a specific image. |
@hectorj2f While I was trying to test your proposed changes, I have noticed that I'm also hitting this issue. I'm not sure if they are related but the policy-webhook crashes due to the missing certificates, despite having re-created the namespace multiple times.
The webkhook-certs secret is created correctly but the policy-webhook-certs secret contains no data. Perhaps that issue should be re-opened. I will try disabling auto-tls via annotation as per the documentation. Would I need to configure anything else on the policy controller or would it rely on the KNative functionality ? |
You need to delete the leases if you tried reinstalling the chart, that sometimes happens, |
It is a known issue the webhooks are not able to re-claim the leases, we haven't figured it out yet how to solve it. So the recommendation consists on deleting the leases when the pods are not getting ready. |
@hectorj2f Thank you. I did delete the leases before posting above. I did so before deleting the namespace and re-installing the chart, but the issue with the certificates was still present. I haven't had the opportunity to test without auto-tls yet though. |
@gustavoromerobenitez I just tried and the problem goes away by deleting the chart (waiting until is properly deleted), then deleted the leases and reinstalled. If your problem persists we could try increasing the leader election time. The problem goes also away when using multiple replicas instead of the default which uses a single replica. We'll unify the controllers into a single pod so it'd be easier to increase the amount of replicas by default. |
Description
I'm testing the policy-controller in an air-gapped environment using GKE and a private container registry. I have deployed it via the official Helm chart in its own namespace
security-enforcement
.I'm also using a custom
registryCaBundle
andimage-pull-secrets
, and the webhook can connect to the private registry to resolve tags into digests.The following Extra Args are also set:
policy-resync-period:1m
anddisable-tuf: true
.After trying more complex configurations and policies without success, I wanted to test the simplest possible ClusterImagePolicy:
but I get the following error with that policy and any other I have tried (including
mode: warn
):I've tried with other Glob patterns, like including the full path of the image in the registry, but to no avail.
Could you tell me why the policy is not matched ?
Should I be concerned about those TrustRoot errors or can they be ignored or suppressed ?
Thank you.
Version
policy-controller AppVersion: 0.7.0
policy-controller Helm Chart version: 0.5.4
Kubernetes (GKE) version: 1.24.9-gke.3200
The text was updated successfully, but these errors were encountered: