The example of disallowed/allowed ingress resources in the unique ingress host example has incorrect hostnames

[WilliamRockwellEvans]

Link: https://open-policy-agent.github.io/gatekeeper-library/website/validation/uniqueingresshost/
The constraint template example uses a simple host_1 == host_2 logic, but the allowed and disallowed examples don't share the same host name -- accordingly the disallowed resource isn't blocked.

example-allowed:
example-allowed-host.example.com
example-allowed-host1.example.com

example-disallowed:
example-host.example.com

example-disallowed2:
example-host2.example.com
example-host3.example.com

[apeabody]

Hi Everyone!

There are three independent tests cases/samples, the resources aren't shared between them:

https://github.com/open-policy-agent/gatekeeper-library/blob/master/library/general/uniqueingresshost/suite.yaml

  - name: example-allowed
    object: samples/unique-ingress-host/example_allowed.yaml
    assertions:
    - violations: no
  - name: example-disallowed
    object: samples/unique-ingress-host/example_disallowed.yaml
    inventory:
    - samples/unique-ingress-host/example_inventory_disallowed.yaml
    assertions:
    - violations: yes
  - name: example-disallowed2
    object: samples/unique-ingress-host/example_disallowed2.yaml
    inventory:
    - samples/unique-ingress-host/example_inventory_disallowed2.yaml
    assertions:
    - violations: yes

example-allowed: (0 violations)

• example-allowed-host.example.com
• example-allowed-host1.example.com

example-disallowed: (1 violation)

• example-host.example.com
• example-host.example.com

example-disallowed2: (1 violation)

• example-host2.example.com
• example-host3.example.com
• example-host2.example.com

@JaydipGabani - These tests appears to be working as intended to me, can you confirm?

[JaydipGabani]

@apeabody I think the issue refers to the information that is directly user-facing on the library website where the available allowed and disallowed examples appear to have not been violating the policy.

As in if user if trying out the policy,

• user applies the policy
• user applies allowed example
• then user applies disallowed example expecting it to generate violation/get denied - the host does not match currently between allowed and disallowed - but the disallowed object gets created leaving the user thinking the policy is faulty

The tests are working as intended as inventory is in direct conflict with examples however inventory objects are not part of the policy documentation on the website. So on the website, naming examples allowed and disallowed makes it so that user might think these provided examples are supposed to be conflicting - that is the case for many policies that do not require sync as far as I can tell.

[apeabody]

Thanks @JaydipGabani!

I think the issue refers to the information that is directly user-facing on the library website where the available allowed and disallowed examples appear to have not been violating the policy.

Got it, makes total sense. Would it perhaps be more sustainable to automate inclusion of the "missing inventory resources into the documentation examples? This gap could potentially apply to all templates/samples which use data.inventory, and it might not be feasible to manually "fix" all of them in this manner. Nor do we have any sort of automated testing to avoid drift in the future.

[JaydipGabani]

@apeabody Agreed! I took a look and there are some policies that uses data,inventory. For instance - hpa policy requires additional nginx deployment to exists out of box.

Do you suggest merging the associated PR for this and fixing this for now and opening a new issue to fix a greater problem?
or do you want to close this issue without merging the PR and open a new issue to fix a greater problem?

[apeabody]

Do you suggest merging the associated PR for this and fixing this for now and opening a new issue to fix a greater problem?
or do you want to close this issue without merging the PR and open a new issue to fix a greater problem?

No concerns with the current PR. :) More a point that the tests are working as intended, so the PR is a workaround for what is really a documentation gap. So we should have an open issue to fix that regardless.

[stale]

This issue/PR 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.

[JaydipGabani]

still valid

[stale]

This issue/PR 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.

[JaydipGabani]

Not stale

[stale]

This issue/PR 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.