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

Improvements to secret injector #13282

Conversation

jim-minter
Copy link
Contributor

Disallow @ character in host component of URL patterns, so that people don't mistakenly try to add URL patterns of the form user@host.

Extend admission controller to reject invalid URL patterns on secrets to provide early feedback to end users when their patterns are wrong.

@@ -105,6 +116,30 @@ func (si *secretInjector) Admit(attr admission.Attributes) (err error) {
return nil
}

func (si *secretInjector) admitSecret(attr admission.Attributes, secret *api.Secret) (err error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

can't this be part of the static validation logic for secrets, or that's not an option because it's an upstream object so we can't override/extend the validation logic?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assumed it's not an option for the reason you mention.

@@ -12,7 +12,7 @@ var InvalidPatternError = errors.New("invalid pattern")

var urlPatternRegex = regexp.MustCompile(`^` +
`(?:(\*|git|http|https|ssh)://)` +
`(\*|(?:\*\.)?[^/*]+)` +
`(\*|(?:\*\.)?[^@/*]+)` +
`(/.*)` +
`$`)
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 should be disallowing this for all users of the utility, since technically urls containing @ can be valid, even though you want to disallow it in your particular usage.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We're disallowing @ in the host part of the /pattern/, not in the URL matched. A pattern of http://example.com/* would still match the URL http://user:password@example.com/ (although I'll add a test case for this). I want to disable @ in the pattern because I don't think it makes any sense for us to match user:password@ in the URL.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Test cases added.

Copy link
Contributor

Choose a reason for hiding this comment

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

you don't think we'd have a case where we want to ensure a user name is being supplied in the url, as for an ssh url?

we might not need it today, i'm not convinced we wouldn't want it in the future, but i guess i'm ok with adding this restriction for now.

@jim-minter jim-minter force-pushed the secret-injector-improvements branch from 85a5ea3 to f5df357 Compare March 9, 2017 10:32
}

if secret, ok := obj.(*api.Secret); ok {
return si.admitSecret(attr, secret)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

i suspect @smarterclayton may have strong opinions about adding this admission control check.

@bparees
Copy link
Contributor

bparees commented Mar 16, 2017

lgtm as long as @smarterclayton doesn't veto the use of admission control for this (due to added overhead)

@smarterclayton
Copy link
Contributor

Veto. We don't use admission for validation, and doing this here is wrong in lots of ways. Also, people may already have these, so you have to suck it up a bit. If you want to report broken secrets, fail the build.

@smarterclayton
Copy link
Contributor

Can talk tomorrow and go over it.

@jim-minter
Copy link
Contributor Author

@smarterclayton the motivation here is to provide rapid feedback when the annotation added to the secret does not parse, in order to make the situation less confusing to the person adding the annotation. Is there an alternative way to meet this goal?

@smarterclayton
Copy link
Contributor

smarterclayton commented Mar 16, 2017 via email

@jim-minter
Copy link
Contributor Author

OK, I think that means that all we can do is log the fact that the annotation didn't parse to the master log when at some point we touch it, which is what we do today. Is that correct?

@smarterclayton
Copy link
Contributor

smarterclayton commented Mar 17, 2017 via email

@jim-minter
Copy link
Contributor Author

The documentation suggests using oc annotate secret, but it could also be via oc edit secret or via the web yaml editor, for example.

@jim-minter
Copy link
Contributor Author

@smarterclayton is there anything useful that can come out of this PR, or should I just abandon it?

@bparees
Copy link
Contributor

bparees commented Apr 26, 2017

@smarterclayton bump

@jim-minter jim-minter force-pushed the secret-injector-improvements branch from 77d631c to 280217a Compare May 8, 2017 09:54
@openshift-merge-robot openshift-merge-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. and removed approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jul 24, 2017
… try

to add URL patterns of the form username@hostname/path.
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 11, 2017
@openshift-ci-robot openshift-ci-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Sep 11, 2017
@jim-minter
Copy link
Contributor Author

@bparees removed the admission controller pieces from this and rebased - ptal

@bparees
Copy link
Contributor

bparees commented Sep 11, 2017

@jim-minter so what's the net effect of this change? who are the consumers that are impacted? any effect on existing objects in clusters?

@bparees
Copy link
Contributor

bparees commented Sep 15, 2017

@jim-minter bump

@jim-minter
Copy link
Contributor Author

/retest

@jim-minter
Copy link
Contributor Author

@bparees tbh, minimal effect. Whereas previously an invalid url pattern of the form *://user@host/* would have parsed but failed to match anything, now it will fail to parse causing a glog.V(2).Infof to be emitted to the master log. Wider behaviour remains the same - BC object passes through and is created. No effect on existing objects.

@bparees
Copy link
Contributor

bparees commented Sep 16, 2017

thanks @jim-minter
/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 16, 2017
@openshift-merge-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees, jim-minter

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

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 16, 2017
@openshift-merge-robot
Copy link
Contributor

/test all [submit-queue is verifying that this PR is safe to merge]

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue (batch tested with PRs 16269, 13282, 16386)

@openshift-merge-robot openshift-merge-robot merged commit a4e5e53 into openshift:master Sep 16, 2017
@openshift-ci-robot
Copy link

openshift-ci-robot commented Sep 16, 2017

@jim-minter: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/openshift-jenkins/end_to_end ae22665 link /test end_to_end

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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

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. lgtm Indicates that a PR is ready to be merged. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants