Skip to content
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

Gatekeeper Does not trigger on run pod #3538

Closed
lir1ka opened this issue Sep 10, 2024 · 6 comments
Closed

Gatekeeper Does not trigger on run pod #3538

lir1ka opened this issue Sep 10, 2024 · 6 comments
Labels
bug Something isn't working stale

Comments

@lir1ka
Copy link

lir1ka commented Sep 10, 2024

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

I am testing gatekeeper in testing cluster. I block access to gatekeeper pods to check what will happen in this situation.

When i try to create namespace:

Error from server (InternalError): Internal error occurred: failed calling webhook "check-ignore-label.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.gatekeeper-system.svc:443/v1/admitlabel?timeout=3s": dial tcp 10.112.0.99:8443: i/o timeout

So, it is normal behavior

But when i use command kubectl run pod:

user@vmfordeploy:~/terraform-newlife$   kubectl run nginx --image=nginx
pod/nginx created

Gatekeeper did not block this operation and i created pod without any problems. Why?

What did you expect to happen:
Gatekeeper block creation of resource.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

  • Gatekeeper version: 3.16.3
  • Kubernetes version: (use kubectl version): v1.29.1
@lir1ka lir1ka added the bug Something isn't working label Sep 10, 2024
@sozercan
Copy link
Member

sozercan commented Sep 11, 2024

@lir1ka what you are seeing is expected behavior in kubernetes webhooks, and if Gatekeeper controller deployments are not accessible. Please see https://open-policy-agent.github.io/gatekeeper/website/docs/failing-closed for further information

@lir1ka
Copy link
Author

lir1ka commented Sep 12, 2024

@sozercan, hello! I Understood, that it is expected behavior (in situation with inability to create namespace). But still i dont understand why i can create pod

@JaydipGabani
Copy link
Contributor

@lir1ka You need to set validatingWebhookFailurePolicy: Fail if using helm, or set failurePolicy: Fail (default is Ignore) for validation.gatekeeper.sh (used for all admission events) webhook - https://github.com/open-policy-agent/gatekeeper/blob/master/deploy/gatekeeper.yaml#L5205 - to deny the creation of pod.

The situation you are facing is caused by, check-ignore-label.gatekeeper.sh webhook (used only for namespace admission events)- https://github.com/open-policy-agent/gatekeeper/blob/master/deploy/gatekeeper.yaml#L5251 with default failurePolicy set to Fail. You can use validatingWebhookCheckIgnoreFailurePolicy helm variable to update failurePolicy for check-ignore-label.gatekeeper.sh webhook.

@lir1ka
Copy link
Author

lir1ka commented Sep 24, 2024

The situation you are facing is caused by, check-ignore-label.gatekeeper.sh webhook (used only for namespace admission events)- https://github.com/open-policy-agent/gatekeeper/blob/master/deploy/gatekeeper.yaml#L5251 with default failurePolicy set to Fail. You can use validatingWebhookCheckIgnoreFailurePolicy helm variable to update failurePolicy for check-ignore-label.gatekeeper.sh webhook.

@JaydipGabani, Hello! Thank you for your answer. Overall, could you please describe, what check-ignore-label.gatekeeper.sh do? and what is ignore-label?

@JaydipGabani
Copy link
Contributor

@lir1ka This webhook validates namespaces to make sure "only allowed namespaces are using admission.gatekeeper.sh/ignore label label to prevent Gatekeeper validation webhook from being called by api-server for respective namespace". Here is some more information on the same. For more information/context - here is the pr - #350

Copy link

stale bot commented Nov 30, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 30, 2024
@stale stale bot closed this as completed Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale
Projects
None yet
Development

No branches or pull requests

3 participants