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

sarapprover: remove self node cert #62471

Merged
merged 1 commit into from
Apr 13, 2018

Conversation

mikedanese
Copy link
Member

@mikedanese mikedanese commented Apr 12, 2018

The functionality to bootstrap node certificates is ready but is blocked by a separable issue discussed in: kubernetes/community#1982. The functionality could be useful for power users who want to write their own approvers if the feature could be promoted to beta. In it's current state this feature doesn't help anybody.

I propose that we remove automated approval of node serving certificates for now and work towards getting the node functionality to beta.

cc @awly @kubernetes/sig-auth-pr-reviews

Remove alpha functionality that allowed the controller manager to approve kubelet server certificates.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Apr 12, 2018
@mikedanese
Copy link
Member Author

/retest

@rtripat
Copy link
Contributor

rtripat commented Apr 12, 2018

@mikedanese Will the kubelet continue to have the ability to request a server certificate as an alpha feature?

@ericchiang
Copy link
Contributor

ericchiang commented Apr 12, 2018

+1 from me

@@ -201,28 +192,3 @@ func isSelfNodeClientCert(csr *capi.CertificateSigningRequest, x509cr *x509.Cert
}
return true
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Unrelated to this change but what do you think about adding debug logging in the recognizer's about the exact condition which led to CSR not being approved?

Copy link
Member Author

Choose a reason for hiding this comment

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

Events are better for exposing reasons to end users. Would this be for certs that are recognized but the subject access review is denied?

Copy link
Contributor

@rtripat rtripat Apr 12, 2018

Choose a reason for hiding this comment

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

Not so much for the SAR since I think the result of that request will show up in API server logs at appropriate verbosity.

If we can have greater visibility via logs or events into which condition in the recognizer failed to approve the CSR that will be great.

This is more useful when someone generates their own bootstrap token and wants to debug why their CSR isn't being approved. Otherwise, the controller leaves the CSR in pending without any trace in the logs. Example: username of token should match the CommonName in CSR like system:node:$NodeName

Copy link
Member Author

Choose a reason for hiding this comment

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

Debug logging might be ok but not all CSRs are expected to be approved by this controller. Unrecognized CSRs are expected under normal circumstances.

@mikedanese
Copy link
Member Author

mikedanese commented Apr 12, 2018

@mikedanese Will the kubelet continue to have the ability to request a server certificate as an alpha feature?

The motivation for this change is that the kubelet piece can cease to be alpha, and become beta.

func TestRecognizers(t *testing.T) {
goodCases := []func(b *csrBuilder){
func(b *csrBuilder) {
},
}

testRecognizer(t, goodCases, isNodeClientCert, true)
testRecognizer(t, goodCases, isSelfNodeClientCert, true)
Copy link
Member

Choose a reason for hiding this comment

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

did you mean to remove the self client cert cases?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch

@liggitt
Copy link
Member

liggitt commented Apr 13, 2018

question on the removed client cert cases, lgtm otherwise

The functionality to bootstrap node certificates is ready but is blocked
by a seperable issue discussed in:
kubernetes/community#1982. The functionality
could be useful for power users who want to write their own approvers if
the feature could be promoted to beta. In it's current state this
feature doesn't help anybody.

I propose that we remove automated approval of node serving certificates
for now and work towards getting the node functionality to beta.
@liggitt
Copy link
Member

liggitt commented Apr 13, 2018

/lgtm

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

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, mikedanese

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 added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 13, 2018
@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 62486, 62471, 62183). If you want to cherry-pick this change to another branch, please follow the instructions here.

@k8s-github-robot k8s-github-robot merged commit eca4d03 into kubernetes:master Apr 13, 2018
@mikedanese mikedanese deleted the certs2 branch April 13, 2018 23:26
@rbtr
Copy link

rbtr commented Aug 7, 2019

@mikedanese Apologies for the zombie thread - I'm trying to follow all the work around Kubelet server cert signing and not quite sure where to ask this -
since the Kubelet can submit a CSR for its server cert, do you think it would be sufficient to automatically approve that Kubelet server cert iff the following can be verified?

  • the certificate is shaped like a Kubelet cert
  • the requestor is authorized to create a CSR (via SAR)
  • the requestor metadata matches the cert Subject and SANs
  • that the Subject and SANs represent a known compute instance by querying the cloud provider

I think from reading all the issues and docs around this that the final check is key in that it uses a trusted third party to verify the node metadata/labels that we can't trust the node to set on itself, and we should then be able to approve the CSR. I'm implementing a CSR approving controller to use until the protected node labels work settles and would appreciate your thoughts on this.

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. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/auth Categorizes an issue or PR as relevant to SIG Auth. 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.

None yet

7 participants