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

Add ability to specify allowed CNs for RequestHeader proxy client cert #8443

Merged
merged 1 commit into from
Apr 12, 2016
Merged

Add ability to specify allowed CNs for RequestHeader proxy client cert #8443

merged 1 commit into from
Apr 12, 2016

Conversation

liggitt
Copy link
Contributor

@liggitt liggitt commented Apr 11, 2016

Allows requiring a particular CN, so that not all client certs issued by the CA have to be trusted.

@liggitt
Copy link
Contributor Author

liggitt commented Apr 11, 2016

suggestions welcome for the config field name
@deads2k @sgallagher ptal

if a.allowedCommonNames.Has(subject.CommonName) {
return nil
}
return fmt.Errorf("x509: subject with cn=%s is not allowed", subject.CommonName)
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 going to assume that you're intentionally withholding the allowed set on the assumption that while a compromised signer means you're owned, they wouldn't be able to also trick openshift without either access to the master-config or the client cert from the existing proxy?

Seems a little thin to me, but if you want it that way, you should add a comment and maybe indicate where in the master-config they should look when they're rejected?

@deads2k
Copy link
Contributor

deads2k commented Apr 11, 2016

lgtm. Is this for 1.2 or 1.2.x?

@liggitt
Copy link
Contributor Author

liggitt commented Apr 11, 2016

added integration tests (and made sure the old integration test still passed against the current code):

  • valid signature+invalid cn
  • invalid signature+valid cn

@liggitt
Copy link
Contributor Author

liggitt commented Apr 11, 2016

[test]

@deads2k
Copy link
Contributor

deads2k commented Apr 11, 2016

lgtm

@smarterclayton for approval. fwiw, I'd vote yes.

@smarterclayton
Copy link
Contributor

Risk?

@deads2k
Copy link
Contributor

deads2k commented Apr 11, 2016

Risk?

Given the testing around it and the simplicity of the code, I'd say low.

@liggitt
Copy link
Contributor Author

liggitt commented Apr 12, 2016

bindata failure, re[test]

@smarterclayton smarterclayton added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 12, 2016
@smarterclayton
Copy link
Contributor

Approved per importance to setting up request proxies

@liggitt
Copy link
Contributor Author

liggitt commented Apr 12, 2016

flake on #7429, re[test]
[merge]

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5578/) (Image: devenv-rhel7_3957)

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 0ffdfdd

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 0ffdfdd

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/2947/)

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants