https://issues.redhat.com/browse/ACM-26213 note about fail-over #8417
Conversation
| *Important:* | ||
|
|
||
| Gatekeeper policy support:: Red Hat supports only the Gatekeeper Operator. Individual Gatekeeper policies are not supported. Support ensures that the operator is functioning. |
There was a problem hiding this comment.
Are the individual policies not supported by Red Hat? If so, let's remove passive voice, like IBM SG suggests when we can:
| Gatekeeper policy support:: Red Hat supports only the Gatekeeper Operator. Individual Gatekeeper policies are not supported. Support ensures that the operator is functioning. | |
| Gatekeeper policy support:: Red Hat supports only the Gatekeeper Operator and does not support individual Gatekeeper policies. Support ensures that the operator is functioning. |
|
|
||
| Gatekeeper policy support:: Red Hat supports only the Gatekeeper Operator. Individual Gatekeeper policies are not supported. Support ensures that the operator is functioning. | ||
|
|
||
| Default fail-open behavior:: By default, Gatekeeper is configured to fail open. If the Gatekeeper webhook becomes unavailable, requests to the Kubernetes API are not blocked. To learn about configuring the {gate}, see _Configuring the {gate}_. For more information about configuring fail-open and fail-closed behavior, see link:https://open-policy-agent.github.io/gatekeeper/website/docs/howto/failopen/[Gatekeeper documentation]. |
There was a problem hiding this comment.
"fail open" is not a phrase I'm usd to. it also seems a little colloquial. Do you mean any of these meanings?
Gatekeeper is configured to fail.
Gatekeeper is configured to instantly fail.
Gatekeeper is configured to fail and let you know when it does.
These are ideas. It seems to me that "open" conveys that it's obvious to the user when Gatekeeper fails, and there's nothing hidden or unexpected about its failure.
There was a problem hiding this comment.
Later, I see you have "fail open" behavior. So if that's a term that Gatekeeper users would be familiar with, keep it :)
There was a problem hiding this comment.
Based on the Gatekeeper docs, it seems like it will be familiar to the user. I agree that it is a bit confusing. In the Gatekeeper docs, there is a specific parameter named failurePolicy. When failurePolicy is set to Ignore, constraints are not enforced when the webhook is unreachable.
Let me add that to help
|
|
||
| Gatekeeper policy support:: Red Hat supports only the Gatekeeper Operator. Individual Gatekeeper policies are not supported. Support ensures that the operator is functioning. | ||
|
|
||
| Default fail-open behavior:: By default, Gatekeeper is configured to fail open. If the Gatekeeper webhook becomes unavailable, requests to the Kubernetes API are not blocked. To learn about configuring the {gate}, see _Configuring the {gate}_. For more information about configuring fail-open and fail-closed behavior, see link:https://open-policy-agent.github.io/gatekeeper/website/docs/howto/failopen/[Gatekeeper documentation]. |
There was a problem hiding this comment.
Is the italicized Doc part of the link you provide? If so, that could be easier for users to find if we re-write it to something like the following:
| Default fail-open behavior:: By default, Gatekeeper is configured to fail open. If the Gatekeeper webhook becomes unavailable, requests to the Kubernetes API are not blocked. To learn about configuring the {gate}, see _Configuring the {gate}_. For more information about configuring fail-open and fail-closed behavior, see link:https://open-policy-agent.github.io/gatekeeper/website/docs/howto/failopen/[Gatekeeper documentation]. | |
| Default fail-open behavior:: By default, Gatekeeper is configured to fail open. If the Gatekeeper webhook becomes unavailable, requests to the Kubernetes API are not blocked. To learn about configuring the {gate} and the fail-open and fail-closed behavior, see _Configuring the {gate}_ in the link:https://open-policy-agent.github.io/gatekeeper/website/docs/howto/failopen/[Gatekeeper documentation]. |
There was a problem hiding this comment.
It is italicized because the doc is already linked within this file. Christine wanted me to let the user know that they can change the failurePolicy parameter. From my perspective, we shouldn't be adding a task to the file bc it is more of an overview. I thought it be best to just link to the doc where the task is listed. Again, let me make that more clear in the doc
Removed prereqs bc this is not a task file.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dockerymick, jc-berger, yiraeChristineKim The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3 participants
No description provided.