-
Notifications
You must be signed in to change notification settings - Fork 111
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
block illegal calls in inpod mode #935
block illegal calls in inpod mode #935
Conversation
Part of istio#928 This removes the obsolete call protections for inpod, and adds equivilents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have data to back it but I'm suspicious that ~4 elements just using a vec might be the cheaper option.
Otherwise looks good
@@ -12,6 +12,7 @@ | |||
// See the License for the specific language governing permissions and | |||
// limitations under the License. | |||
|
|||
use std::collections::HashSet; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is hash necessary? Could we just use a vec, sort it once during init and then efficiently search it without calculating hashes on the u16. Because its small we could probably just iterate for a match instead of sort/binary search even
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not, but its just 1 instance with like 4 keys and we Arc it anyways so doesn't seem so bad?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is all that would be pretty close to a wash with just using a vanilla HashSet, and somewhat less readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if I start feeling froggy maybe I'll test it and let ya know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Smarter illegal port registration would be nice, but that's largely a cosmetic concern ATM.
@@ -155,13 +157,19 @@ impl Proxy { | |||
Self::from_inputs(pi, drain).await | |||
} | |||
pub(super) async fn from_inputs(mut pi: ProxyInputs, drain: Watch) -> Result<Self, Error> { | |||
// illegal_ports are internal ports that clients are not authorized to send to | |||
let mut illegal_ports: HashSet<u16> = HashSet::new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like it would be nice to have a ProxyHandler type, have Proxies.handlers()
and then be able to register all the illegal_ports for all handlers in a loop, but that might be overkill ATM.
(was gonna suggest maybe these ports should be in ProxyInfo
but then I remembered that type is already overstuffed with random crap)
@@ -12,6 +12,7 @@ | |||
// See the License for the specific language governing permissions and | |||
// limitations under the License. | |||
|
|||
use std::collections::HashSet; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is all that would be pretty close to a wash with just using a vanilla HashSet, and somewhat less readable.
Part of #928
This removes the obsolete call protections for inpod, and adds
equivilents