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

feat: add deny-label-ns flag which supports wildcard #1051

Conversation

AhmedGrati
Copy link

Resolves #1022.

Signed-off-by: AhmedGrati [email protected]

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Feb 6, 2023
@k8s-ci-robot
Copy link
Contributor

Hi @AhmedGrati. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

@netlify
Copy link

netlify bot commented Feb 6, 2023

Deploy Preview for kubernetes-sigs-nfd ready!

Name Link
🔨 Latest commit b499799
🔍 Latest deploy log https://app.netlify.com/sites/kubernetes-sigs-nfd/deploys/63ec9c0d3d0ff0000869fe07
😎 Deploy Preview https://deploy-preview-1051--kubernetes-sigs-nfd.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@k8s-ci-robot k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Feb 6, 2023
Copy link
Contributor

@marquiz marquiz left a comment

Choose a reason for hiding this comment

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

Thanks @AhmedGrati for working on this!

I don't think we want to replace -extra-label-ns, just add -deny-label-ns on top of that. This will allow strict namespace control (if a user wants that) e.g. with

-deny-label-ns="*" -extra-label-ns=example.com

you could deny everything but example.com, kind of mimicking what we currently do

/ok-to-test

@@ -449,6 +451,17 @@ func verifyNodeName(cert *x509.Certificate, nodeName string) error {
return nil
}

func isNamespaceDenied(labelNs string, deniedNs map[string]struct{}) bool {
for ns := range deniedNs {
deniedNsWildcard := fmt.Sprintf("*.%v", ns)
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we want to forcibly make all items a glob. Otherwise you couldn't do something like "deny kubernetes.io but allow all *.kubernetes.io"

Copy link
Author

@AhmedGrati AhmedGrati Feb 8, 2023

Choose a reason for hiding this comment

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

Yes true, but I just followed what was said here. Which means basically denying all namespaces. In fact, the user will input a namespace (without wildcard) and we will deny all sub-namespaces by default.
However, If you see that we need to give users the flexibility to deny all sub-namespaces using wildcards, I think we should change this implementation above.

Copy link
Contributor

Choose a reason for hiding this comment

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

It can be that what I suggested above is not the "right thing to do". NOT forcing a glob (i.e. not automatically denying sub-namespaces) would give us the most flexibility. I now feel that if we forcibly deny all sub-namespaces it will bit us later (could be countered by supporting wildcards in -extra-label-ns though)

Let's see what others think. Any thoughts on this @cedricmckinnie @ArangoGutierrez @zvonkok @fmuyassarov ?

Copy link
Author

Choose a reason for hiding this comment

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

Yes, I agree with you!

Comment on lines 457 to 458
g := glob.MustCompile(deniedNsWildcard)
if g.Match(labelNs) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not entirely sure we need to support full-fledged globs (performance, extra external dependency), we could probably do away with something like

if strings.HasPrefix(ns, "*") {
    deniedSuffix := strings.TrimLeft(ns, "*")
    if strings.HasSuffix(labelNs, deniedSuffix) {
        return true
    }
} else if labelNs == ns {
    return true
}
return false

And just document that we support asterisk ("*") in front of the name to deny all sub-namespaces. WDYT?

Also, we probably want to pre-process the user input at startup to repeat same string (or glob) operations over and over again.

Copy link
Author

Choose a reason for hiding this comment

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

Yes got it, and it's a valid point I think. I just didn't understand the last point. Can you explain it to me further, please?

Copy link
Contributor

@marquiz marquiz Feb 9, 2023

Choose a reason for hiding this comment

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

Can you explain it to me further, please?

My point is that in the current implementation for each label we create, we run through the deny list and do glob.MustCompile for each deny item. That is for each time a label request arrives, for each label, for each item in deny list do compile. Even though that information is basically static, doing compile once at the startup would be enough and save a lot of cpu cycles

Same could basically be applied to the simplified poor-man's asterisk-based I proposed. I.e. pre-process the deny list to two separate lists, one to do exact matches (==) and one to do suffixes (HasSuffix())

Copy link
Author

Choose a reason for hiding this comment

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

@marquiz what about having working with such wildcards: prefix.*.suffix. The aesterik-based implementation won't work in the expected way. isn't it?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's just me, but I wouldn't be concerned about complex regexs or globs at the moment. Think about how domain names and IP addresses generally work, for example, you don't generally specify IP ranges like 192.168.*.3. For sub-namespaces I see a clear use case, though. More advanced globbing can be added later if it is clearly needed

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Feb 8, 2023
}

flagset.StringVar(&args.CaFile, "ca-file", "",
"Root certificate for verifying connections")
flagset.StringVar(&args.CertFile, "cert-file", "",
"Certificate used for authenticating connections")
flagset.Var(&args.ExtraLabelNs, "extra-label-ns",
Copy link
Contributor

Choose a reason for hiding this comment

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

@marquiz should we have both flags at least for a release, having ExtraLabelNS to print a deprecation warning? I feel that removing the flag all together could break some users deployments if they try a roll-update and the pod get's called with old flags.
WDYT?

Copy link
Author

Choose a reason for hiding this comment

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

@marquiz suggested that we keep the extra-label-ns flag because that would give flexibility to our users.

Copy link
Contributor

Choose a reason for hiding this comment

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

@ArangoGutierrez yes, I don't see any reason removing the existing flag. It will also give flexibility in enabling scenarios like "deny all except for example.com/ and acme.io/"

@AhmedGrati AhmedGrati force-pushed the feat-add-deny-label-ns-with-wildcard branch from c9695a1 to 2b927c8 Compare February 11, 2023 11:04
@AhmedGrati AhmedGrati changed the title feat: replace extra-label-ns with deny-label-ns flag which supports wildcard feat: add deny-label-ns flag which supports wildcard Feb 11, 2023
@AhmedGrati AhmedGrati force-pushed the feat-add-deny-label-ns-with-wildcard branch 2 times, most recently from e1eff45 to 5182050 Compare February 11, 2023 11:11
@AhmedGrati AhmedGrati requested review from marquiz and removed request for adrianchiris and fmuyassarov February 12, 2023 10:11
Copy link
Contributor

@ArangoGutierrez ArangoGutierrez left a comment

Choose a reason for hiding this comment

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

PR looks good now
Leaving the lgtm to @marquiz

Copy link
Contributor

@marquiz marquiz left a comment

Choose a reason for hiding this comment

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

Thanks for the update @AhmedGrati

I think we need to adjust the docs a bit more, probably removing all references to -extra-label-ns in docs/usage/customization-guide.md and also adjust description of -extra-label-ns in docs/reference/master-commandline-reference.md to match the new behavior.

cmd/nfd-master/main.go Outdated Show resolved Hide resolved
pkg/nfd-master/nfd-master.go Outdated Show resolved Hide resolved
@AhmedGrati
Copy link
Author

@marquiz why should we remove all references to -extra-label-ns in docs/usage/customization-guide.md?

@marquiz
Copy link
Contributor

marquiz commented Feb 13, 2023

@marquiz why should we remove all references to -extra-label-ns in docs/usage/customization-guide.md?

Heh, my comment wasn't very clear 😇 I should've written that review all references to -extra-label-ns in the doc. IIRC it's mentioned in few places, saying that by default all namespaces except for '*.feature.node.kubernetes.io` are denied... which obviously isn't true anymore after this PR so we could just remove those mentions

@AhmedGrati
Copy link
Author

@marquiz why should we remove all references to -extra-label-ns in docs/usage/customization-guide.md?

Heh, my comment wasn't very clear 😇 I should've written that review all references to -extra-label-ns in the doc. IIRC it's mentioned in few places, saying that by default all namespaces except for '*.feature.node.kubernetes.io` are denied... which obviously isn't true anymore after this PR so we could just remove those mentions

Oh yes got it now, thank you 😊

@AhmedGrati AhmedGrati force-pushed the feat-add-deny-label-ns-with-wildcard branch from 5182050 to 1b46830 Compare February 13, 2023 16:49
@AhmedGrati AhmedGrati requested review from marquiz and ArangoGutierrez and removed request for marquiz February 13, 2023 16:49
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Feb 13, 2023
@AhmedGrati
Copy link
Author

@marquiz I added the fact that we'll forcibly deny the *.kubernetes.io namespace.

@marquiz
Copy link
Contributor

marquiz commented Feb 14, 2023

but setting directly the mockMaster.deniedNs, won't cover the test of the preProcessing part of the DeniedLabelNs. For the moment, I think it should be done that way.

That is very much true. D'ya have plans for adding e2e-tests? 😉

@AhmedGrati
Copy link
Author

@marquiz I'll work on adding the e2e tests, but it'll take me some time.

@marquiz
Copy link
Contributor

marquiz commented Feb 14, 2023

@marquiz I'll work on adding the e2e tests, but it'll take me some time.

No worries, that would be really cool. I think we can take that as a separate PR

@AhmedGrati
Copy link
Author

Okay then, I'll finish the requested changes and I'll create a separate issue and PR for the e2e tests.

@AhmedGrati AhmedGrati force-pushed the feat-add-deny-label-ns-with-wildcard branch 3 times, most recently from 9f9badd to 1d5fead Compare February 14, 2023 16:12
@AhmedGrati AhmedGrati requested review from marquiz and ArangoGutierrez and removed request for marquiz and ArangoGutierrez February 14, 2023 16:12
Copy link
Contributor

@marquiz marquiz left a comment

Choose a reason for hiding this comment

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

Thanks @AhmedGrati for the update. Looks like we're almost there, just a few small comments/suggestions

EDIT: also I think you want to drop this from the customization guide:

Note that in the example above `-extra-label-ns=my.namespace` must be specified
on the nfd-master command line.

nfd.deniedNs.wildcard = wildcardDeniedNs
// We forcibly deny kubernetes.io
nfd.deniedNs.normal["kubernetes.io"] = struct{}{}
nfd.deniedNs.wildcard["kubernetes.io"] = struct{}{}
Copy link
Contributor

Choose a reason for hiding this comment

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

To be correct i think we want to deny *.kubernetes.io

Suggested change
nfd.deniedNs.wildcard["kubernetes.io"] = struct{}{}
nfd.deniedNs.wildcard[".kubernetes.io"] = struct{}{}

docs/reference/master-commandline-reference.md Outdated Show resolved Hide resolved
pkg/nfd-master/nfd-master.go Outdated Show resolved Hide resolved
pkg/nfd-master/nfd-master.go Outdated Show resolved Hide resolved
@AhmedGrati AhmedGrati force-pushed the feat-add-deny-label-ns-with-wildcard branch from 1d5fead to b499799 Compare February 15, 2023 08:47
@AhmedGrati AhmedGrati requested a review from marquiz February 15, 2023 09:21
Copy link
Contributor

@marquiz marquiz left a comment

Choose a reason for hiding this comment

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

Thanks @AhmedGrati for your efforts on this! From my perspective this looks good to go 👍

@@ -392,7 +409,7 @@ func (m *nfdMaster) updateMasterNode() error {
// into extended resources. This function also handles proper namespacing of
// labels and ERs, i.e. adds the possibly missing default namespace for labels
// arriving through the gRPC API.
func filterFeatureLabels(labels Labels, extraLabelNs map[string]struct{}, labelWhiteList regexp.Regexp, extendedResourceNames map[string]struct{}) (Labels, ExtendedResources) {
func (m *nfdMaster) filterFeatureLabels(labels Labels) (Labels, ExtendedResources) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks, this looks so much cleaner 👍

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 15, 2023
@marquiz
Copy link
Contributor

marquiz commented Feb 15, 2023

/assign @ArangoGutierrez @fmuyassarov

@AhmedGrati
Copy link
Author

Many thanks for your review @marquiz 👌.

Copy link
Contributor

@ArangoGutierrez ArangoGutierrez left a comment

Choose a reason for hiding this comment

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

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 15, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 1fea083de80ed12d154588ced604dfdc9a91d7be

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AhmedGrati, ArangoGutierrez, marquiz

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

@k8s-ci-robot k8s-ci-robot merged commit a92614c into kubernetes-sigs:master Feb 15, 2023
@marquiz marquiz mentioned this pull request Apr 12, 2023
24 tasks
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. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow wildcard or regrx in "extra label ns"
6 participants