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

WIP: Webhook test refactor #28753

Closed

Conversation

adambkaplan
Copy link
Contributor

Starting in OCP 4.16, the system:webhook ClusterRole will not be
granted to anonymous users by default. This will break most systems
that use BuildConfig webhooks to trigger builds, since many can't be
add an OpenShift auth token to their HTTP headers (ex: GitHub). Only
new installations will be impacted; upgrades to 4.16 will continue to
support unauthenticated BuildConfig webhooks.

This test update verifies that BuildConfig webhooks can be triggered
using a namespace-scoped RoleBinding for the system:unauthenticated
group. RoleBindings are preferable to ClusterRoleBindings as they limit
unauthenticated API calls to specific namespaces, reducing the
potential attack surface. The core webhook tests were also updated to
verify that unauthenticated webhooks fail if this rolebinding is
missing.

Use of BuildConfig webhooks should be discouraged in favor of Pipelines
as Code, which has more robust mechanisms for securing webhook calls
from external systems. It also does not rely on an aggregated apiserver
and associated RBAC.

This PR also includes a refactor of the core BuildConfig webhook test suite, to take advantage of Ginkgo v2's table driven test functions. This makes the test more readable and provides missing context on error.

Starting in OCP 4.16, the `system:webhook` ClusterRole will not be
granted to anonymous users by default. This will break most systems
that use BuildConfig webhooks to trigger builds, since many can't be
add an OpenShift auth token to their HTTP headers (ex: GitHub). Only
new installations will be impacted; upgrades to 4.16 will continue to
support unauthenticated BuildConfig webhooks.

This test update verifies that BuildConfig webhooks can be triggered
using a namespace-scoped RoleBinding for the `system:unauthenticated`
group. RoleBindings are preferable to ClusterRoleBindings as they limit
unauthenticated API calls to specific namespaces, reducing the
potential attack surface. The core webhook tests were also updated to
verify that unauthenticated webhooks fail if this rolebinding is
missing.

Use of BuildConfig webhooks should be discouraged in favor of Pipelines
as Code, which has more robust mechanisms for securing webhook calls
from external systems. It also does not rely on an aggregated apiserver
and associated RBAC.

Signed-off-by: Adam Kaplan <[email protected]>
Use Ginkgo v2's table-driven test functions to make the BuildConfig
webhook tests more readable and produce more context when errors occur.

Signed-off-by: Adam Kaplan <[email protected]>
@adambkaplan
Copy link
Contributor Author

An alternative/follow up to #28750 - I want to see if the table driven test breaks anything.

Copy link
Contributor

openshift-ci bot commented Apr 29, 2024

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: adambkaplan
Once this PR has been reviewed and has the lgtm label, please assign dgoodwin for approval. For more information see the Kubernetes Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@adambkaplan
Copy link
Contributor Author

So good news? When the build test fails, it prints the name of the entry:
image

@adambkaplan adambkaplan changed the title Webhook test refactor WIP: Webhook test refactor Apr 29, 2024
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 29, 2024
Copy link
Contributor

openshift-ci bot commented Apr 29, 2024

@adambkaplan: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-ovn-single-node-serial 35f85a7 link false /test e2e-aws-ovn-single-node-serial
ci/prow/e2e-aws-ovn-cgroupsv2 35f85a7 link false /test e2e-aws-ovn-cgroupsv2
ci/prow/e2e-aws-ovn-upgrade 35f85a7 link false /test e2e-aws-ovn-upgrade
ci/prow/e2e-openstack-ovn 35f85a7 link false /test e2e-openstack-ovn
ci/prow/e2e-aws-ovn-fips 35f85a7 link true /test e2e-aws-ovn-fips
ci/prow/e2e-gcp-ovn-builds 35f85a7 link true /test e2e-gcp-ovn-builds
ci/prow/e2e-aws-ovn-serial 35f85a7 link true /test e2e-aws-ovn-serial
ci/prow/e2e-aws-ovn-single-node 35f85a7 link false /test e2e-aws-ovn-single-node
ci/prow/e2e-aws-ovn-single-node-upgrade 35f85a7 link false /test e2e-aws-ovn-single-node-upgrade
ci/prow/e2e-gcp-ovn 35f85a7 link true /test e2e-gcp-ovn
ci/prow/e2e-metal-ipi-ovn-ipv6 35f85a7 link true /test e2e-metal-ipi-ovn-ipv6
ci/prow/e2e-metal-ipi-sdn 35f85a7 link false /test e2e-metal-ipi-sdn

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@adambkaplan
Copy link
Contributor Author

/close

A worthwhile experiment, but I won't have time to chase down this NPE.

@openshift-ci openshift-ci bot closed this Apr 29, 2024
Copy link
Contributor

openshift-ci bot commented Apr 29, 2024

@adambkaplan: Closed this PR.

In response to this:

/close

A worthwhile experiment, but I won't have time to chase down this NPE.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant