fix: add NetworkPolicy for DSP apiserver pod self traffic #719
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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