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

fix: add NetworkPolicy for DSP apiserver pod self traffic #719

Merged
merged 1 commit into from
Oct 17, 2024

Conversation

gregsheremeta
Copy link
Contributor

Description of your changes:

The DSP apiserver implements TLS by relying on the OpenShift service cert signer. In order to get this to work nicely with our openshift-oauth sidecar, we set the Kubernetes service as the upstream for the oauth container. This means that all incoming traffic to DSP goes like this:
client -> DSP service -> DSP oauth -> DSP service -> DSP apiserver
DSP oauth and DSP apiserver are in the same pod. We haven't explicitly created a NetworkPolicy to allow that, but it works on AWS and OpenStack-based clusters. For some yet to be determined reason, it doesn't work on IBM / Calico / Secure-By-Default clusters.

Add a NetworkPolicy entry to allow the DSP pod to talk to itself on 8888 and 8887. This fixes the issue where DSP(oauth) can't talk to DSP(apiserver) via the service (that fronts both containers / the pod).

The issue resolved by this Pull Request:

Resolves https://issues.redhat.com/browse/RHOAIENG-14571

Testing instructions

Provision a managed IBM Cloud OpenShift with SBD enabled.
Install the master release of DSPO. Create a DSPA. Verify that you can't connect to this DSPA's route. You'll see timeout errors in the DSPA oauth containter log.
Update to this PR's build of DSPO. Create another DSPA. Verify that you CAN connect to this DSPA's route. You won't see timeout errors in the DSPA oauth containter log.

Checklist

  • The commits are squashed in a cohesive manner and have meaningful messages.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work

The DSP apiserver implements TLS by relying on the OpenShift
service cert signer. In order to get this to work nicely with
our openshift-oauth sidecar, we set the Kubernetes service as
the upstream for the oauth container. This means that all incoming
traffic to DSP goes like this:
`client -> DSP service -> DSP oauth -> DSP service -> DSP apiserver`
DSP oauth and DSP apiserver are in the same pod. We haven't explicitly
created a NetworkPolicy to allow that, but it works on AWS and
OpenStack-based clusters. For some yet to be determined reason,
it doesn't work on IBM / Calico / Secure-By-Default clusters.

Add a NetworkPolicy entry to allow the DSP pod to talk to itself
on 8888 and 8887. This fixes the issue where DSP(oauth) can't talk
to DSP(apiserver) via the service (that fronts both containers /
the pod).

Fixes: https://issues.redhat.com/browse/RHOAIENG-14571

Signed-off-by: Greg Sheremeta <gshereme@redhat.com>
@gregsheremeta
Copy link
Contributor Author

/cc @jgarciao

@openshift-ci openshift-ci bot requested a review from jgarciao October 16, 2024 22:52
@dsp-developers
Copy link
Contributor

A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-719
An OCP cluster where you are logged in as cluster admin is required.

To use this image run the following:

cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines-operator.git
cd data-science-pipelines-operator/
git fetch origin pull/719/head
git checkout -b pullrequest 1667e6d394c329c3f806783029abe3c5db78b448
oc new-project opendatahub
make deploy IMG="quay.io/opendatahub/data-science-pipelines-operator:pr-719"

More instructions here on how to deploy and test a Data Science Pipelines Application.

Copy link
Contributor

openshift-ci bot commented Oct 17, 2024

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jgarciao
Once this PR has been reviewed and has the lgtm label, please ask for approval from gregsheremeta. 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

@HumairAK HumairAK merged commit 86d1236 into opendatahub-io:main Oct 17, 2024
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants