Skip to content

Conversation

@Clee2691
Copy link
Contributor

@Clee2691 Clee2691 commented Nov 13, 2025

Description

This PR refactors the NetworkPolicy feature to improve port handling and configuration robustness, which also resolves the following issues: LOG-8109 and LOG-8091.

Changes:

  • Automatically use standard ports (80/443) for HTTP/HTTPS URLs if no port is specified.
  • Fail immediately if non-standard schemes (UDP, TLS, TCP) are used without an explicit port.
  • Correctly parse and aggregate ports for all configured Kafka brokers and URLs.
  • Now correctly parse the proxyURL for HTTP outputs.
  • Use HTTPS port 443 by default for GCL, Azure
  • Use HTTPS port 443 by default for Cloudwatch, and S3 outputs when a URL is undefined.

This PR will supersede: #3152.

/cc @cahartma @vparfonov
/assign @jcantrill

Links

@Clee2691
Copy link
Contributor Author

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 13, 2025
port = parsedPort
// Panic on non-standard schemes without a port
} else if parsedURL.Scheme != "http" && parsedURL.Scheme != "https" {
panic(fmt.Sprintf("non-standard scheme %q requires an explicit port in URL %q", parsedURL.Scheme, urlStr))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would mean we allowed an 'address:port' without the port? The offenders I can think of our the socket level outputs like kafka or syslog. Admins need to specify the port for even forwarding to work but my concern is we do not have validation at admission that would catch a missing port and panic for the operator looks agressive.

I think 'panic' is the right approach if we are certain we have plenty of safeguards upstream of this call. Are we able to confirm that? Can we add validations (declarative) if we do not? I know we have isURL in place but I do not believe that will catch a requirement of 'address:port'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct. We do allow non standard schemes without a port as the validations do that check for that. We will need to add validation for these URLs. I am fine either way not panicking if we can validate all URLs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do allow non standard schemes without a port as the validations do that check for that

We do...and validations check(and fail)... if ⬅️ is the current behavior then let's leave the panic in

Copy link
Contributor Author

@Clee2691 Clee2691 Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake on that comment, we DO NOT check for that. isURL() only checks if it is a proper url even if not port is specified.

For something like Kafka, validation only ensures the URL starts with tcp or tls but doesn't check for a port. We DON'T have a validation for ensuring ports exist for those URLs.

I believe we should add in validations for non standard schemes to ensure they also include a port. Then we can keep this panic.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be able to add regex into the declarative validations to enforce port specification. Please either add this to this PR or open a new JIRA so we capture the work for later.

@Clee2691
Copy link
Contributor Author

/retest

@Clee2691
Copy link
Contributor Author

/retest

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 15, 2025

@Clee2691: all tests passed!

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-sigs/prow repository. I understand the commands that are listed here.

@jcantrill
Copy link
Contributor

/approve

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 18, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Clee2691, jcantrill

The full list of commands accepted by this bot can be found here.

The pull request process is described 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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 18, 2025
Copy link
Contributor

@jcantrill jcantrill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. release/6.4

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants