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

kubectl should support CertificateSigningRequest #30163

Closed
mikedanese opened this Issue Aug 5, 2016 · 22 comments

Comments

Projects
None yet
8 participants
@mikedanese
Member

mikedanese commented Aug 5, 2016

The basic crud ops are a bit wonky right now:

$ jsonnet csr.jsonnet 
{
   "apiVersion": "certificates/v1alpha1",
   "kind": "CertificateSigningRequest",
   "spec": {
      "request": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1dqQ0NBVUlDQVFBd0ZURVRNQkVHQTFVRUF3d0tiV2xyWldSaGJtVnpaVENDQVNJd0RRWUpLb1pJaHZjTgpBUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTEEyVVUvWWRUNW9jbFRRWTRNTjB3UXorcTU3bEg2ZHVrNkp6WEhJCkFqQkFRYjJQakFWSUU4NGxFVm8xcjFnT2JWdjJyY0RqZG9EOS9YbDd0NzVXbzZlVkpqUUw0SnJEM043LzRhQ2oKQ1huY0JpZTBOQnhWQnRTMXZNYkdtcnRxcFN4cWZLRSs5bEc5eHZvdHZhQzJoRlZScDRrTGVCendURTZQZGtSMwo1eWxIcTZjMHVhL1c4aGR0SURXUllsbmZxR21aVTYwM09TOXgvKzltQmFyTDlsK041MldHTDd6a0ZlK2w1ZDFzCjd5L0lQMzd0WGJXUDAyTWJhZlF2OUNRUFM4UFVib0VLai85UnFnVllYazBkUlNtdytkd3lKTmJhdUxWU0hCWjQKc3E1azlYYm9kKzJQQ2s3eGgvbmxTT1ZHRnJiTC9HUktNQWhwenBmd1M1SmVMbmNDQXdFQUFhQUFNQTBHQ1NxRwpTSWIzRFFFQkN3VUFBNElCQVFDT0lQd29Ccy9jRXBqQ1FuQ2UzZ0huSk1rTFd6NWdld1BQOHV5d0JmeUdMV244CjJNbmdhMWszNkdFK2VyY2R5ei9mSDJJbW5yYTRMRWtQK2xZUmQ2QnlROFlkbHBMcE1UR1BhNkgvRzBGdENFQXkKRnZjcFFZYjNNUDFPZVJETmpDb3BiYWx5SGNKL0swTHhCUUZBYjY0SnVFUUxDbFNnOERwTURQTDlZNnI5Z0xyYwp1QXc5ZCtISGhsTjRQQ2ZOME9OWkZkcUFjRDdvM2VmQkxqd25hUWNQWEE2WHhzTnpEN1g2R1ZmSUVxWG5Fa2QxCmFOekg2MCtUYXBNSEZZU3pyRVZNYTFJcDZ2MzVHSSsxcWQrU0h3T05ldnRYQnpBZ2FZNVo5ZUoyZGpqaW1OV3oKaHBRdjBtR1BWeE50aHU1Y0hvdm5UYjJyQkRpbmlERVNOcDJKSmQwTQotLS0tLUVORCBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0K",
      "username": "mikedanese"
   }
}
$ jsonnet csr.jsonnet | k create -f -                 
error validating "STDIN": error validating data: expected type array, for field spec.request, got string; if you choose to ignore these errors, turn validation off with --validate=false
$ jsonnet csr.jsonnet | k create --validate=false -f -
certificatesigningrequest "mikedanese" created
$ kubectl get csr
error: unknown type &certificates.CertificateSigningRequest{TypeMeta:unversioned.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:api.ObjectMeta{Name:"mikedanese", GenerateName:"", Namespace:"", SelfLink:"/apis/certificates/v1alpha1/certificatesigningrequests/mikedanese", UID:"baeb4f1b-5b4d-11e6-9235-42010af00002", ResourceVersion:"13670", Generation:0, CreationTimestamp:unversioned.Time{Time:time.Time{sec:63606026808, nsec:0, loc:(*time.Location)(0x20e80e0)}}, DeletionTimestamp:(*unversioned.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]api.OwnerReference(nil), Finalizers:[]string(nil)}, Spec:certificates.CertificateSigningRequestSpec{Request:[]uint8{0x2d, 0x2d, 0x2d, 0x2d, 0x2d, 0x42, 0x45, 0x47, 0x49, 0x4e, 0x20, 0x43, 0x45, 0x52, 0x54, 0x49, 0x46, 0x49, 0x43, 0x41, 0x54, 0x45, 0x20, 0x52, 0x45, 0x51, 0x55, 0x45, 0x53, 0x54, 0x2d, 0x2d, 0x2d, 0x2d, 0x2d, 0xa, 0x4d, 0x49, 0x49, 0x43, 0x57, 0x6a, 0x43, 0x43, 0x41, 0x55, 0x49, 0x43, 0x41, 0x51, 0x41, 0x77, 0x46, 0x54, 0x45, 0x54, 0x4d, 0x42, 0x45, 0x47, 0x41, 0x31, 0x55, 0x45, 0x41, 0x77, 0x77, 0x4b, 0x62, 0x57, 0x6c, 0x72, 0x5a, 0x57, 0x52, 0x68, 0x62, 0x6d, 0x56, 0x7a, 0x5a, 0x54, 0x43, 0x43, 0x41, 0x53, 0x49, 0x77, 0x44, 0x51, 0x59, 0x4a, 0x4b, 0x6f, 0x5a, 0x49, 0x68, 0x76, 0x63, 0x4e, 0xa, 0x41, 0x51, 0x45, 0x42, 0x42, 0x51, 0x41, 0x44, 0x67, 0x67, 0x45, 0x50, 0x41, 0x44, 0x43, 0x43, 0x41, 0x51, 0x6f, 0x43, 0x67, 0x67, 0x45, 0x42, 0x41, 0x4c, 0x41, 0x32, 0x55, 0x55, 0x2f, 0x59, 0x64, 0x54, 0x35, 0x6f, 0x63, 0x6c, 0x54, 0x51, 0x59, 0x34, 0x4d, 0x4e, 0x30, 0x77, 0x51, 0x7a, 0x2b, 0x71, 0x35, 0x37, 0x6c, 0x48, 0x36, 0x64, 0x75, 0x6b, 0x36, 0x4a, 0x7a, 0x58, 0x48, 0x49, 0xa, 0x41, 0x6a, 0x42, 0x41, 0x51, 0x62, 0x32, 0x50, 0x6a, 0x41, 0x56, 0x49, 0x45, 0x38, 0x34, 0x6c, 0x45, 0x56, 0x6f, 0x31, 0x72, 0x31, 0x67, 0x4f, 0x62, 0x56, 0x76, 0x32, 0x72, 0x63, 0x44, 0x6a, 0x64, 0x6f, 0x44, 0x39, 0x2f, 0x58, 0x6c, 0x37, 0x74, 0x37, 0x35, 0x57, 0x6f, 0x36, 0x65, 0x56, 0x4a, 0x6a, 0x51, 0x4c, 0x34, 0x4a, 0x72, 0x44, 0x33, 0x4e, 0x37, 0x2f, 0x34, 0x61, 0x43, 0x6a, 0xa, 0x43, 0x58, 0x6e, 0x63, 0x42, 0x69, 0x65, 0x30, 0x4e, 0x42, 0x78, 0x56, 0x42, 0x74, 0x53, 0x31, 0x76, 0x4d, 0x62, 0x47, 0x6d, 0x72, 0x74, 0x71, 0x70, 0x53, 0x78, 0x71, 0x66, 0x4b, 0x45, 0x2b, 0x39, 0x6c, 0x47, 0x39, 0x78, 0x76, 0x6f, 0x74, 0x76, 0x61, 0x43, 0x32, 0x68, 0x46, 0x56, 0x52, 0x70, 0x34, 0x6b, 0x4c, 0x65, 0x42, 0x7a, 0x77, 0x54, 0x45, 0x36, 0x50, 0x64, 0x6b, 0x52, 0x33, 0xa, 0x35, 0x79, 0x6c, 0x48, 0x71, 0x36, 0x63, 0x30, 0x75, 0x61, 0x2f, 0x57, 0x38, 0x68, 0x64, 0x74, 0x49, 0x44, 0x57, 0x52, 0x59, 0x6c, 0x6e, 0x66, 0x71, 0x47, 0x6d, 0x5a, 0x55, 0x36, 0x30, 0x33, 0x4f, 0x53, 0x39, 0x78, 0x2f, 0x2b, 0x39, 0x6d, 0x42, 0x61, 0x72, 0x4c, 0x39, 0x6c, 0x2b, 0x4e, 0x35, 0x32, 0x57, 0x47, 0x4c, 0x37, 0x7a, 0x6b, 0x46, 0x65, 0x2b, 0x6c, 0x35, 0x64, 0x31, 0x73, 0xa, 0x37, 0x79, 0x2f, 0x49, 0x50, 0x33, 0x37, 0x74, 0x58, 0x62, 0x57, 0x50, 0x30, 0x32, 0x4d, 0x62, 0x61, 0x66, 0x51, 0x76, 0x39, 0x43, 0x51, 0x50, 0x53, 0x38, 0x50, 0x55, 0x62, 0x6f, 0x45, 0x4b, 0x6a, 0x2f, 0x39, 0x52, 0x71, 0x67, 0x56, 0x59, 0x58, 0x6b, 0x30, 0x64, 0x52, 0x53, 0x6d, 0x77, 0x2b, 0x64, 0x77, 0x79, 0x4a, 0x4e, 0x62, 0x61, 0x75, 0x4c, 0x56, 0x53, 0x48, 0x42, 0x5a, 0x34, 0xa, 0x73, 0x71, 0x35, 0x6b, 0x39, 0x58, 0x62, 0x6f, 0x64, 0x2b, 0x32, 0x50, 0x43, 0x6b, 0x37, 0x78, 0x68, 0x2f, 0x6e, 0x6c, 0x53, 0x4f, 0x56, 0x47, 0x46, 0x72, 0x62, 0x4c, 0x2f, 0x47, 0x52, 0x4b, 0x4d, 0x41, 0x68, 0x70, 0x7a, 0x70, 0x66, 0x77, 0x53, 0x35, 0x4a, 0x65, 0x4c, 0x6e, 0x63, 0x43, 0x41, 0x77, 0x45, 0x41, 0x41, 0x61, 0x41, 0x41, 0x4d, 0x41, 0x30, 0x47, 0x43, 0x53, 0x71, 0x47, 0xa, 0x53, 0x49, 0x62, 0x33, 0x44, 0x51, 0x45, 0x42, 0x43, 0x77, 0x55, 0x41, 0x41, 0x34, 0x49, 0x42, 0x41, 0x51, 0x43, 0x4f, 0x49, 0x50, 0x77, 0x6f, 0x42, 0x73, 0x2f, 0x63, 0x45, 0x70, 0x6a, 0x43, 0x51, 0x6e, 0x43, 0x65, 0x33, 0x67, 0x48, 0x6e, 0x4a, 0x4d, 0x6b, 0x4c, 0x57, 0x7a, 0x35, 0x67, 0x65, 0x77, 0x50, 0x50, 0x38, 0x75, 0x79, 0x77, 0x42, 0x66, 0x79, 0x47, 0x4c, 0x57, 0x6e, 0x38, 0xa, 0x32, 0x4d, 0x6e, 0x67, 0x61, 0x31, 0x6b, 0x33, 0x36, 0x47, 0x45, 0x2b, 0x65, 0x72, 0x63, 0x64, 0x79, 0x7a, 0x2f, 0x66, 0x48, 0x32, 0x49, 0x6d, 0x6e, 0x72, 0x61, 0x34, 0x4c, 0x45, 0x6b, 0x50, 0x2b, 0x6c, 0x59, 0x52, 0x64, 0x36, 0x42, 0x79, 0x51, 0x38, 0x59, 0x64, 0x6c, 0x70, 0x4c, 0x70, 0x4d, 0x54, 0x47, 0x50, 0x61, 0x36, 0x48, 0x2f, 0x47, 0x30, 0x46, 0x74, 0x43, 0x45, 0x41, 0x79, 0xa, 0x46, 0x76, 0x63, 0x70, 0x51, 0x59, 0x62, 0x33, 0x4d, 0x50, 0x31, 0x4f, 0x65, 0x52, 0x44, 0x4e, 0x6a, 0x43, 0x6f, 0x70, 0x62, 0x61, 0x6c, 0x79, 0x48, 0x63, 0x4a, 0x2f, 0x4b, 0x30, 0x4c, 0x78, 0x42, 0x51, 0x46, 0x41, 0x62, 0x36, 0x34, 0x4a, 0x75, 0x45, 0x51, 0x4c, 0x43, 0x6c, 0x53, 0x67, 0x38, 0x44, 0x70, 0x4d, 0x44, 0x50, 0x4c, 0x39, 0x59, 0x36, 0x72, 0x39, 0x67, 0x4c, 0x72, 0x63, 0xa, 0x75, 0x41, 0x77, 0x39, 0x64, 0x2b, 0x48, 0x48, 0x68, 0x6c, 0x4e, 0x34, 0x50, 0x43, 0x66, 0x4e, 0x30, 0x4f, 0x4e, 0x5a, 0x46, 0x64, 0x71, 0x41, 0x63, 0x44, 0x37, 0x6f, 0x33, 0x65, 0x66, 0x42, 0x4c, 0x6a, 0x77, 0x6e, 0x61, 0x51, 0x63, 0x50, 0x58, 0x41, 0x36, 0x58, 0x78, 0x73, 0x4e, 0x7a, 0x44, 0x37, 0x58, 0x36, 0x47, 0x56, 0x66, 0x49, 0x45, 0x71, 0x58, 0x6e, 0x45, 0x6b, 0x64, 0x31, 0xa, 0x61, 0x4e, 0x7a, 0x48, 0x36, 0x30, 0x2b, 0x54, 0x61, 0x70, 0x4d, 0x48, 0x46, 0x59, 0x53, 0x7a, 0x72, 0x45, 0x56, 0x4d, 0x61, 0x31, 0x49, 0x70, 0x36, 0x76, 0x33, 0x35, 0x47, 0x49, 0x2b, 0x31, 0x71, 0x64, 0x2b, 0x53, 0x48, 0x77, 0x4f, 0x4e, 0x65, 0x76, 0x74, 0x58, 0x42, 0x7a, 0x41, 0x67, 0x61, 0x59, 0x35, 0x5a, 0x39, 0x65, 0x4a, 0x32, 0x64, 0x6a, 0x6a, 0x69, 0x6d, 0x4e, 0x57, 0x7a, 0xa, 0x68, 0x70, 0x51, 0x76, 0x30, 0x6d, 0x47, 0x50, 0x56, 0x78, 0x4e, 0x74, 0x68, 0x75, 0x35, 0x63, 0x48, 0x6f, 0x76, 0x6e, 0x54, 0x62, 0x32, 0x72, 0x42, 0x44, 0x69, 0x6e, 0x69, 0x44, 0x45, 0x53, 0x4e, 0x70, 0x32, 0x4a, 0x4a, 0x64, 0x30, 0x4d, 0xa, 0x2d, 0x2d, 0x2d, 0x2d, 0x2d, 0x45, 0x4e, 0x44, 0x20, 0x43, 0x45, 0x52, 0x54, 0x49, 0x46, 0x49, 0x43, 0x41, 0x54, 0x45, 0x20, 0x52, 0x45, 0x51, 0x55, 0x45, 0x53, 0x54, 0x2d, 0x2d, 0x2d, 0x2d, 0x2d, 0xa}, Username:"mikedanese", UID:"", Groups:[]string(nil)}, Status:certificates.CertificateSigningRequestStatus{Conditions:[]certificates.CertificateSigningRequestCondition(nil), Certificate:[]uint8(nil)}}

We should also consider adding some porcelain commands:

$ kubectl certificates approve
$ kubectl certificates deny

We also need to implement a describer.

ref kubernetes/features#43

cc @gtank @kubernetes/sig-cluster-lifecycle

@mikedanese mikedanese changed the title from kubectl should support CertificateSigningRequest= to kubectl should support CertificateSigningRequest Aug 5, 2016

@zhouhaibing089

This comment has been minimized.

Show comment
Hide comment
@zhouhaibing089

zhouhaibing089 Aug 7, 2016

Contributor

Is it possible to set the type of Request being string?

Contributor

zhouhaibing089 commented Aug 7, 2016

Is it possible to set the type of Request being string?

@zhouhaibing089

This comment has been minimized.

Show comment
Hide comment
@zhouhaibing089

zhouhaibing089 Aug 7, 2016

Contributor

And what's the policy to tell who has the permission to approve or deny this CSR?

Contributor

zhouhaibing089 commented Aug 7, 2016

And what's the policy to tell who has the permission to approve or deny this CSR?

@timothysc

This comment has been minimized.

Show comment
Hide comment
@timothysc
Member

timothysc commented Aug 8, 2016

/cc @liggitt

@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Aug 8, 2016

Member

@zhouhaibing089 You should be able to use the ABAC admission controller or other Auhorization mechanisms.

Member

mikedanese commented Aug 8, 2016

@zhouhaibing089 You should be able to use the ABAC admission controller or other Auhorization mechanisms.

@liggitt

This comment has been minimized.

Show comment
Hide comment
@liggitt

liggitt Aug 8, 2016

Member

are the approve/deny operations modeled as subresources?

Member

liggitt commented Aug 8, 2016

are the approve/deny operations modeled as subresources?

@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Aug 8, 2016

Member

ok PRs for this are mostly out and linked to this. We are waiting one upstream fix emicklei/go-restful#311

@pwittrock this is what i'd like to get into kubectl for v1.4.

Member

mikedanese commented Aug 8, 2016

ok PRs for this are mostly out and linked to this. We are waiting one upstream fix emicklei/go-restful#311

@pwittrock this is what i'd like to get into kubectl for v1.4.

@mikedanese mikedanese added this to the v1.4 milestone Aug 8, 2016

@liggitt

This comment has been minimized.

Show comment
Hide comment
@liggitt

liggitt Aug 8, 2016

Member

RBAC supports policy around approval subresource by defining a role containing a rule like this:

{
  "verb":     ["update"],
  "group":    ["certificates"],
  "resources":["certificatesigningrequests/approve"]
}
Member

liggitt commented Aug 8, 2016

RBAC supports policy around approval subresource by defining a role containing a rule like this:

{
  "verb":     ["update"],
  "group":    ["certificates"],
  "resources":["certificatesigningrequests/approve"]
}
@liggitt

This comment has been minimized.

Show comment
Hide comment
@liggitt

liggitt Aug 8, 2016

Member

the username should be populated by the API server, not sent in the API request - opened #30239 to track that

Member

liggitt commented Aug 8, 2016

the username should be populated by the API server, not sent in the API request - opened #30239 to track that

@liggitt

This comment has been minimized.

Show comment
Hide comment
@liggitt

liggitt Aug 9, 2016

Member

We also need to implement a describer.

When implementing the describer, I think these things are really important to show to an admin who is deciding whether to approve/reject a CSR:

  1. who requested it (as recorded by the API server)
  2. the requested subject/CN/SANs
  3. the requested key usages (TLS server, TLS client, Certificate Sign, unrestricted, etc) and value of a CA Basic Constraint (if present)

kubectl certificates approve

When approving, is there a way via the API to specify which profile the server should use to sign the cert? It seems like approving a CSR being issued a cert using a specific signing profile (e.g. "3-month-server", "1-year-client-cert") would be common.

Member

liggitt commented Aug 9, 2016

We also need to implement a describer.

When implementing the describer, I think these things are really important to show to an admin who is deciding whether to approve/reject a CSR:

  1. who requested it (as recorded by the API server)
  2. the requested subject/CN/SANs
  3. the requested key usages (TLS server, TLS client, Certificate Sign, unrestricted, etc) and value of a CA Basic Constraint (if present)

kubectl certificates approve

When approving, is there a way via the API to specify which profile the server should use to sign the cert? It seems like approving a CSR being issued a cert using a specific signing profile (e.g. "3-month-server", "1-year-client-cert") would be common.

k8s-merge-robot added a commit that referenced this issue Aug 9, 2016

Merge pull request #30236 from mikedanese/csr-approval
Automatic merge from submit-queue

csr: add approval to the typed client

ref #30163

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/kubernetes/30236)
<!-- Reviewable:end -->
@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Aug 9, 2016

Member

Signing profiles sound like a good extension to this feature. Allowed usage and validity period would be attributes of the signing profile. Right now, these attributes are not easy to display in kubectl describe. cc @gtank

Member

mikedanese commented Aug 9, 2016

Signing profiles sound like a good extension to this feature. Allowed usage and validity period would be attributes of the signing profile. Right now, these attributes are not easy to display in kubectl describe. cc @gtank

@liggitt

This comment has been minimized.

Show comment
Hide comment
@liggitt
Member

liggitt commented Aug 9, 2016

@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Aug 9, 2016

Member

hmm, ok I will fact check that.

Member

mikedanese commented Aug 9, 2016

hmm, ok I will fact check that.

@gtank

This comment has been minimized.

Show comment
Hide comment
@gtank

gtank Aug 9, 2016

I talked to one of the cfssl maintainers about this, and his take is that including key usage extensions in the CSR itself would be strange - they always use the CA configuration to fill those in. It's ultimately up to the CA to decide what usages and durations it will allow based on its own issuance policy.

cfssl's default config that we're using currently does grant the basics https://github.com/cloudflare/cfssl/blob/master/config/config.go#L599

gtank commented Aug 9, 2016

I talked to one of the cfssl maintainers about this, and his take is that including key usage extensions in the CSR itself would be strange - they always use the CA configuration to fill those in. It's ultimately up to the CA to decide what usages and durations it will allow based on its own issuance policy.

cfssl's default config that we're using currently does grant the basics https://github.com/cloudflare/cfssl/blob/master/config/config.go#L599

@liggitt

This comment has been minimized.

Show comment
Hide comment
@liggitt

liggitt Aug 9, 2016

Member

including key usage extensions in the CSR itself would be strange - they always use the CA configuration to fill those in

Ok, good to know. It does seem like the requester needs a way to indicate the requested usage (client, server, etc). I had assumed that would be expressed in the CSR, but it sounds like that isn't typical. I would not expect components requesting a serving cert to get a cert that was also valid as a client cert.

Member

liggitt commented Aug 9, 2016

including key usage extensions in the CSR itself would be strange - they always use the CA configuration to fill those in

Ok, good to know. It does seem like the requester needs a way to indicate the requested usage (client, server, etc). I had assumed that would be expressed in the CSR, but it sounds like that isn't typical. I would not expect components requesting a serving cert to get a cert that was also valid as a client cert.

@gtank

This comment has been minimized.

Show comment
Hide comment
@gtank

gtank Aug 9, 2016

@liggitt The cfssl API and config files have a concept of multiple signing profiles you can request. For now, I think it makes sense that the bootstrapped kubelet gets both server and client usages. But as this API moves toward stable and other components start using it, we definitely should support multiple profiles.

gtank commented Aug 9, 2016

@liggitt The cfssl API and config files have a concept of multiple signing profiles you can request. For now, I think it makes sense that the bootstrapped kubelet gets both server and client usages. But as this API moves toward stable and other components start using it, we definitely should support multiple profiles.

k8s-merge-robot added a commit that referenced this issue Aug 15, 2016

Merge pull request #30166 from mikedanese/csr-print
Automatic merge from submit-queue

add a certificate signing request resource printer in kubectl

#30163

mfojtik pushed a commit to mfojtik/kubernetes that referenced this issue Aug 17, 2016

Merge pull request #30165 from mikedanese/shortname
Automatic merge from submit-queue

add shortname for certificate signing request in kubectl

#30163
@goltermann

This comment has been minimized.

Show comment
Hide comment
@goltermann

goltermann Sep 6, 2016

Contributor

@mikedanese was this done for 1.4?

Contributor

goltermann commented Sep 6, 2016

@mikedanese was this done for 1.4?

@mikedanese mikedanese modified the milestones: v1.5, v1.4 Sep 6, 2016

@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Sep 6, 2016

Member

Yes.

Member

mikedanese commented Sep 6, 2016

Yes.

@goltermann goltermann closed this Sep 6, 2016

@mikedanese mikedanese reopened this Sep 6, 2016

@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Sep 6, 2016

Member

I meant to say that we are done for v1.4, so I moved to the v1.5 milestone. There are still some open PRs, e.g. #30237

Member

mikedanese commented Sep 6, 2016

I meant to say that we are done for v1.4, so I moved to the v1.5 milestone. There are still some open PRs, e.g. #30237

k8s-merge-robot added a commit that referenced this issue Nov 10, 2016

Merge pull request #30237 from mikedanese/csr-porcelain
Automatic merge from submit-queue

implement kubectl procelain csr commands

cc @gtank

ref #30163
@dims

This comment has been minimized.

Show comment
Hide comment
@dims

dims Nov 15, 2016

Member

ok to move this to 1.6? please holler if not appropriate

Member

dims commented Nov 15, 2016

ok to move this to 1.6? please holler if not appropriate

@dims dims modified the milestones: v1.6, v1.5 Nov 15, 2016

@mikedanese mikedanese modified the milestones: v1.5, v1.6 Nov 15, 2016

@mikedanese

This comment has been minimized.

Show comment
Hide comment
@mikedanese

mikedanese Nov 15, 2016

Member

This is done.

Member

mikedanese commented Nov 15, 2016

This is done.

@mikedanese mikedanese closed this Nov 15, 2016

@dims

This comment has been minimized.

Show comment
Hide comment
@dims

dims Nov 15, 2016

Member

Excellent, Thanks @mikedanese

Member

dims commented Nov 15, 2016

Excellent, Thanks @mikedanese

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment