kube-apiserver: add a bootstrap token authenticator for TLS bootstrapping #41281

ericchiang · 2017-02-11T01:18:11Z

Follows up on #36101

Still needs:

More tests.
To be hooked up to the API server.
- Do I have to do that in a separate PR after k8s.io/apiserver is synced?
Docs (kubernetes.io PR).
Figure out caching strategy.
Release notes.

cc @kubernetes/sig-auth-api-reviews @liggitt @luxas @jbeda

Added a new secret type "bootstrap.kubernetes.io/token" for dynamically creating TLS bootstrapping bearer tokens.

k8s-reviewable · 2017-02-11T01:19:17Z

This change is

luxas

Great start!

I had some comments initially, PTAL

/cc @deads2k @sttts who are familiar with k8s.io/apiserver in general

luxas · 2017-02-11T16:17:44Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+)
+
+// SecretLister is a Kubernetes clients which can list secrets in a namespace.
+type SecretLister interface {


Could we instead do something like this so it's possible to pass a client-go ClientSet to it for example?

// SecretsGetter has a method to return a SecretInterface. // A group's client should implement this interface. type SecretsGetter interface { Secrets(namespace string) SecretInterface } // SecretInterface has methods to work with Secret resources. type SecretInterface interface { List(opts meta_v1.ListOptions) (*v1.SecretList, error) }

(taken from https://github.com/kubernetes/client-go/blob/master/kubernetes/typed/core/v1/secret.go)
Maybe the client-go clientset would do the caching for us then?

Probably some kind of informer should be used for secret lookup.

@ericchiang Can you add a secret informer here then?

Informer or internal storage access?

luxas · 2017-02-11T16:17:58Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

@@ -0,0 +1,97 @@
+/*
+Copyright 2016 The Kubernetes Authors.


2017 now :)

luxas · 2017-02-11T16:18:40Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+
+import (
+	"k8s.io/apiserver/pkg/authentication/user"
+	"k8s.io/kubernetes/pkg/api"


Maybe it's better to depend on client-go here? I see that other parts of k8s.io/apiserver do so

Right, use client-go from the apiserver for kube types. Compare e.g. the webhook authn plugin.

I was trying to mimic the service account authenticator[0] and that uses the API server's internal storage directly[1]. That uses the API server package[2].

I planned to hook it up the same way we do the service account authenticator, and that's why it's this way. Is the service account authenticator using old practices?

[0]

kubernetes/pkg/kubeapiserver/authenticator/config.go

Line 69 in 8621bd3

ServiceAccountTokenGetter serviceaccount.ServiceAccountTokenGetter

[1]

kubernetes/cmd/kube-apiserver/app/server.go

Line 252 in 8621bd3

authenticatorConfig.ServiceAccountTokenGetter = serviceaccountcontroller.NewGetterFromStorageInterface(storageConfig, storageFactory.ResourcePrefix(api.Resource("serviceaccounts")), storageFactory.ResourcePrefix(api.Resource("secrets")))

[2]

kubernetes/pkg/serviceaccount/jwt.go

Line 32 in 8621bd3

"k8s.io/kubernetes/pkg/api/v1"

Where will your authenticator run if it is part of a kube-aggregator setup? On the aggregator side it won't have access to the internal storage, but has to use client-go. In contrast, some kind of delegation has to take place if it runs on the kube-apiserver side. /cc @deads2k

luxas · 2017-02-11T16:20:28Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+			continue
+		}
+
+		if ts, ok := secret.Data[TokenSecret]; !ok || token != string(ts) {


I think the argument token should equal fmt.Sprintf("%s:%s", secret.Data[TokenID], secret.Data[TokenSecret])

Doesn't that encourage setups reusing the same token-secrets for each token and just switching out the token-id? Why would this be preferred?

Hmm, I'm not sure I follow...
The full token tokenid:tokensecret is given as the token arg, right?
Then comparing that arg to only tokensecret will yield the wong behaviour. Or am I missing something here?

I assumed the header would look like:

Authorization: Bearer (token secret)

Would then map to userid: (token id)

Not:

Authorization: Bearer (token id):(token secret)

Happy to change it.

cc @jbeda @mikedanese I think the token will be

Authorization: Bearer (token id):(token secret)

because that's what we set in kubeconfig.AuthInfo[].Token in the kubeconfig that the kubelet uses

sttts · 2017-02-11T16:56:42Z

@ericchiang no need to wait for k8s.io/apiserver to sync. For internal consumation we have a link in the vendor directory. The staging directory is authorative, just change the code there.

luxas · 2017-02-14T16:38:07Z

@ericchiang Do you need more information or can you update this with the changes requested?

ericchiang · 2017-02-14T16:41:32Z

@luxas fine to make the changes, but I'm still a little confused about where this gets hooked up to the API server. I've normally been adding authentication plugins here: https://github.com/kubernetes/kubernetes/blob/master/pkg/kubeapiserver/authenticator/config.go

But that code gets called from here: https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-apiserver/app/server.go

where we don't use client-go.

liggitt · 2017-02-14T16:45:02Z

a couple lines down, you can see us building a client for portions of the API (like admission plugins, etc) to talk to the API:

client, err := internalclientset.NewForConfig(genericConfig.LoopbackClientConfig)

I'm not sure about using that for an auth plugin, though. @deads2k, opinions?

ericchiang · 2017-02-14T16:59:21Z

@liggitt I think I can compose an internal secret informer from that client: https://godoc.org/k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/core/internalversion

Should I use that instead?

deads2k · 2017-02-14T17:20:11Z

I'm not sure about using that for an auth plugin, though. @deads2k, opinions?

You can use the loopback client config since it's recognized locally and ahead of others.

ericchiang · 2017-02-14T17:52:24Z

@deads2k to reuse the loopback client's shared informer[0], I was going to use the factory it creates[1], however there's no secret informer on that interface so I was going to add one. Is that code generated or manually editable?

[0]

kubernetes/cmd/kube-apiserver/app/server.go

Line 272 in 436fa5c

    
           sharedInformers := informers.NewSharedInformerFactory(nil, client, 10*time.Minute)

[1] https://godoc.org/k8s.io/kubernetes/pkg/controller/informers#SharedInformerFactory

liggitt · 2017-02-14T17:54:32Z

I was going to use the factory it creates[1], however there's no secret informer on that interface so I was going to add one. Is that code generated or manually editable?

@ncdc do you have a shared secret informer in a PR yet?

ncdc · 2017-02-14T17:59:08Z

@liggitt nobody should be using pkg/controller/informers any more for new code. All generated informers are in pkg/client/informers/informers_generated. From an instance of the SharedInformerFactory, you'd do .Core().V1().Secrets() to get access to the one for secrets.

ericchiang · 2017-02-14T19:32:03Z

Updated plugin to use pkg/client/informers/informers_generated. Added a couple more tests and hooked it up to the kube-apiserver.

ericchiang · 2017-02-14T19:32:54Z

pkg/kubeapiserver/authenticator/config.go

@@ -66,7 +66,8 @@ type AuthenticatorConfig struct {
 	RequestHeaderConfig *authenticatorfactory.RequestHeaderConfig

 	// TODO, this is the only non-serializable part of the entire config.  Factor it out into a clientconfig
-	ServiceAccountTokenGetter serviceaccount.ServiceAccountTokenGetter
+	ServiceAccountTokenGetter   serviceaccount.ServiceAccountTokenGetter
+	BootstrapTokenAuthenticator authenticator.Token


cc @liggitt @deads2k what do you think of this? I didn't want this package to import all of the internal generated client.

I can live with it for now, would still like these two fields better factored

ericchiang · 2017-02-14T19:34:19Z

cmd/kube-apiserver/app/server.go

+	// 'pkg/client/informers/informers_generated', the second informer
+	// created here.
+	sharedInformers := informers.NewSharedInformerFactory(nil, client, 10*time.Minute)
+	internalSharedInformers := internalversion.NewSharedInformerFactory(client, 10*time.Minute)


per @ncdc's comments I'm using 'pkg/client/informers/informers_generated' for the bootstrap token secret informer. It seems like the other uses of sharedInformer should switch over to this second informer? cc @deads2k

Yes. I'm tracking my work for that here: https://trello.com/c/kpiFmic9/121-use-generated-shared-informers-listers-everywhere-possible. We also need to decide if the kube-apiserver should switch to using versioned informers instead of internal.

What does the 10*time.Minute do here? Does the user have to wait 10mins for the APIServer to notice that a new token was added?

After hunting it down it looks like how often it calls the underlying cache's resync method. Which seems to be this:

func (c *threadSafeMap) Resync() error { // Nothing to do return nil }

https://github.com/kubernetes/client-go/blob/86a2be1b447d7abddae88de0a5f642935992b803/tools/cache/thread_safe_store.go#L277

So, I'm a bit confused.

This is how often a full resync occurs. A full resync is defined as the shared informer's DeltaFIFO cache re-enqueing every item it has so all listeners can have an opportunity to reprocess them. The correct Resync() function is here (or, the equivalent in the kubernetes repo): https://github.com/kubernetes/client-go/blob/204f12b1f3125cc660f989655af4b5bd83cbd9dd/tools/cache/delta_fifo.go#L507

And no, the user doesn't have to wait 10 minutes for the server to notice a new token was added. The shared informer uses a Reflector, which performs a list of all items currently in existence, then starts watching for modified items. It performs a full resync every 10 minutes (in this example). Also, in the event the watch is closed for some reason, the Reflector relists and rewatches.

luxas

Sweet! I had some nits that could be addressed.
Will test this on my cluster as soon as possible :)

luxas · 2017-02-14T20:17:58Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+	BootstrapUserPrefix = "system:bootstrap:"
+	BootstrapGroup      = "system:bootstrappers"
+
+	kubeSystemNamespace = "kube-system"


There is a constant for this already: k8s.io/apimachinery/apis/meta/v1.NamespaceSystem

Was avoiding the import. I'll switch it.

make the namespace an option when constructing the authenticator and inject it

luxas · 2017-02-14T20:18:41Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+//       name: node-bootstrap-token
+//       namespace: kube-system
+//     data:
+//       token-secret: ( bearer token )


( the private part of the token ) maybe?

luxas · 2017-02-14T20:19:00Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+//     apiVersion: v1
+//     kind: Secret
+//     metadata:
+//       name: node-bootstrap-token


bootstrap-token-( token id )

The name of the token shouldn't matter as we are keying off of the SecretType. We shouldn't make assumptions about the name.

luxas · 2017-02-14T20:20:12Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap.go

+//     type: bootstrap.kubernetes.io/token
+//
+func (t *TokenAuthenticator) AuthenticateToken(token string) (user.Info, bool, error) {
+	secrets, err := t.lister.List(labels.Everything())


Can we only return Secrets of type bootstrap.kubernetes.io/token here?

Not here, but there might be a fancier way of doing it on the informer. Let me look into that.

Not using the shared informer, but look at https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/bootstrap/tokencleaner.go#L75

ericchiang · 2017-02-14T22:58:17Z

staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/bootstrap/bootstrap_test.go

+	"k8s.io/kubernetes/pkg/controller"
+)
+
+type secretLister struct {


woops this isn't used anymore.

ericchiang · 2017-02-21T09:39:54Z

pkg/kubeapiserver/options/authentication.go

@@ -172,6 +183,12 @@ func (s *BuiltInAuthenticationOptions) AddFlags(fs *pflag.FlagSet) {

 	}

+	if s.BootstrapToken != nil {
+		fs.BoolVar(&s.BootstrapToken.Allow, "experimental-bootstrap-token-auth", s.BootstrapToken.Allow, ""+


Flag added here. Defaults to false.

ericchiang · 2017-02-21T09:40:44Z

plugin/pkg/auth/authenticator/token/bootstrap/bootstrap.go

+	secretName := tokenNamePrefix + tokenID
+	secret, err := t.lister.Get(secretName)
+	if err != nil {
+		if errors.IsNotFound(err) {


Hope this is the correct way to do this detection for the internalverison api.

@sttts ^

I guess so, yes

ericchiang · 2017-02-21T09:42:42Z

Having trouble running the hack script to update the docs with the new flag. Seems I need a bigger machine :/

$ ./hack/update-generated-docs.sh 
make: Entering directory '/home/eric/src/k8s.io/kubernetes'
make[1]: Entering directory '/home/eric/src/k8s.io/kubernetes'
make[1]: Leaving directory '/home/eric/src/k8s.io/kubernetes'
+++ [0221 01:36:03] Building the toolchain targets:
    k8s.io/kubernetes/hack/cmd/teststale
    k8s.io/kubernetes/vendor/github.com/jteeuwen/go-bindata/go-bindata
+++ [0221 01:36:03] Generating bindata:
    test/e2e/generated/gobindata_util.go
~/src/k8s.io/kubernetes ~/src/k8s.io/kubernetes/test/e2e/generated
~/src/k8s.io/kubernetes/test/e2e/generated
+++ [0221 01:36:04] Building go targets for linux/amd64:
    cmd/gendocs
    cmd/genkubedocs
    cmd/genman
    cmd/genyaml
    federation/cmd/genfeddocs
# k8s.io/kubernetes/cmd/genkubedocs
/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory

# k8s.io/kubernetes/cmd/genman
/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory

!!! [0221 01:37:50] Call tree:
!!! [0221 01:37:51]  1: /home/eric/src/k8s.io/kubernetes/hack/lib/golang.sh:740 kube::golang::build_binaries_for_platform(...)
!!! [0221 01:37:51]  2: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! [0221 01:37:51] Call tree:
!!! [0221 01:37:51]  1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! [0221 01:37:51] Call tree:
!!! [0221 01:37:51]  1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
Makefile:85: recipe for target 'all' failed
make: *** [all] Error 1
make: Leaving directory '/home/eric/src/k8s.io/kubernetes'
!!! Error in ./hack/update-generated-docs.sh:37
  Error in ./hack/update-generated-docs.sh:37. 'make -C "${KUBE_ROOT}" WHAT="${BINS[*]}"' exited with status 2
Call stack:
  1: ./hack/update-generated-docs.sh:37 main(...)
Exiting with status 1

Expecting verification to fail because of the added flag. Going to try to fix it tomorrow.

sttts · 2017-02-21T09:49:35Z

cmd/kube-apiserver/app/server.go

@@ -270,7 +268,32 @@ func Run(s *options.ServerRunOptions) error {
 		// TODO: get rid of KUBE_API_VERSIONS or define sane behaviour if set
 		glog.Errorf("Failed to create clientset with KUBE_API_VERSIONS=%q. KUBE_API_VERSIONS is only for testing. Things will break.", kubeAPIVersions)
 	}
+
+	// TODO: Internal informers should switch to using 'pkg/client/informers/informers_generated',
+	// the second informer created here. Refactor clients which take the former to accept the latter.


will this be done before merge?

@sttts no, but as a follow-up. It would be really important to get this in today

please clean up the duplicated comments below at least.

sttts · 2017-02-21T09:50:24Z

cmd/kube-apiserver/app/server.go

+	internalSharedInformers := internalversion.NewSharedInformerFactory(client, 10*time.Minute)
+
+	if client == nil {
+		// If the client is nil, the internalSharedInformers is not safe to use. However, we only


the client==nil case here looks "over commented" ;) 3x more or less the same.

It's ok, he actually got asked to clarify it :)

Yeah, I'll try to make this more concise.

sttts · 2017-02-21T09:53:15Z

cmd/kube-apiserver/app/server.go

+
+	apiAuthenticator, securityDefinitions, err := authenticatorConfig.New()
+	if err != nil {
+		return fmt.Errorf("invalid Authentication Config: %v", err)


luxas

LGTM!

Thanks for adding it behind a flag

luxas · 2017-02-21T11:25:40Z

cmd/kube-apiserver/app/server.go

@@ -270,7 +268,32 @@ func Run(s *options.ServerRunOptions) error {
 		// TODO: get rid of KUBE_API_VERSIONS or define sane behaviour if set
 		glog.Errorf("Failed to create clientset with KUBE_API_VERSIONS=%q. KUBE_API_VERSIONS is only for testing. Things will break.", kubeAPIVersions)
 	}
+
+	// TODO: Internal informers should switch to using 'pkg/client/informers/informers_generated',
+	// the second informer created here. Refactor clients which take the former to accept the latter.


@sttts no, but as a follow-up. It would be really important to get this in today

luxas · 2017-02-21T11:28:07Z

plugin/pkg/auth/authenticator/token/bootstrap/bootstrap.go

+	secretName := tokenNamePrefix + tokenID
+	secret, err := t.lister.Get(secretName)
+	if err != nil {
+		if errors.IsNotFound(err) {


@sttts ^

I guess so, yes

luxas · 2017-02-21T15:52:56Z

plugin/pkg/auth/authenticator/token/bootstrap/bootstrap.go

+// because the existing functionality isn't exported or because it is in a
+// package that shouldn't be directly imported by this packages.
+
+const tokenNamePrefix = "bootstrap-token-"


This does now exist in bootstrapapi.BootstrapTokenSecretPrefix

…ping

ericchiang · 2017-02-21T16:47:38Z

plugin/pkg/auth/authenticator/token/bootstrap/bootstrap.go

+		return nil, false, nil
+	}
+
+	secretName := bootstrapapi.BootstrapTokenSecretPrefix + tokenID


Now uses constant defined in pkg/bootstrap/api

ericchiang · 2017-02-21T16:48:21Z

@luxas comments addressed and figured out the flags check.

sttts · 2017-02-21T16:49:28Z

cmd/kube-apiserver/app/server.go

+	internalSharedInformers := internalversion.NewSharedInformerFactory(client, 10*time.Minute)
+
+	if client == nil {
+		// TODO: Remove check once client can never be nil.


jbeda

I'd like more logging here, to be honest. But it isn't worth holding this up and that can come in a new PR.

jbeda · 2017-02-21T19:32:10Z

plugin/pkg/auth/authenticator/token/bootstrap/bootstrap.go

+	}
+
+	secretName := bootstrapapi.BootstrapTokenSecretPrefix + tokenID
+	secret, err := t.lister.Get(secretName)


I feel like adding some logging for each of these failure cases might be really helpful for people. When auth fails it can be super frustrating to figure out what is wrong.

Sounds good. Will follow up once this is merged.

jbeda · 2017-02-21T19:35:58Z

/lgtm

jbeda · 2017-02-21T19:44:44Z

/approve

k8s-github-robot · 2017-02-21T19:45:00Z

[APPROVALNOTIFIER] This PR is APPROVED

The following people have approved this PR: ericchiang, jbeda

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

~~cmd/kube-apiserver/OWNERS~~ [jbeda]
~~hack/OWNERS~~ [jbeda]
~~hack/verify-flags/OWNERS~~ [jbeda]
~~pkg/OWNERS~~ [jbeda]
~~plugin/pkg/auth/OWNERS~~ [jbeda]

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

k8s-github-robot · 2017-02-23T08:11:39Z

Automatic merge from submit-queue (batch tested with PRs 41812, 41665, 40007, 41281, 41771)

@jbeda

Automatic merge from submit-queue Remove the kube-discovery binary from the tree **What this PR does / why we need it**: kube-discovery was a temporary solution to implementing proposal: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bootstrap-discovery.md However, this functionality is now gonna be implemented in the core for v1.6 and will fully replace kube-discovery: - #36101 - #41281 - #41417 So due to that `kube-discovery` isn't used in any v1.6 code, it should be removed. The image `gcr.io/google_containers/kube-discovery-${ARCH}:1.0` should and will continue to exist so kubeadm <= v1.5 continues to work. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: **Release note**: ```release-note Remove cmd/kube-discovery from the tree since it's not necessary anymore ``` @jbeda @dgoodwin @mikedanese @dmmcquay @lukemarsden @errordeveloper @pires

@jbeda

Automatic merge from submit-queue (batch tested with PRs 41530, 44814, 43620, 41985) kube-apiserver: improve bootstrap token authentication error messages This was requested by @jbeda as a follow up to #41281. cc @jbeda @luxas @kubernetes/sig-auth-pr-reviews

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Feb 11, 2017

k8s-github-robot assigned gmarek Feb 11, 2017

k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. release-note-label-needed labels Feb 11, 2017

luxas assigned jbeda and liggitt Feb 11, 2017

luxas added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-label-needed labels Feb 11, 2017

luxas reviewed Feb 11, 2017

View reviewed changes

luxas mentioned this pull request Feb 11, 2017

Add a doc about the kubeadm design and phases implementation kubernetes/kubeadm#156

Merged

luxas self-assigned this Feb 14, 2017

luxas mentioned this pull request Feb 14, 2017

Switch serviceaccounts controller to generated shared informers #41425

Merged

ericchiang force-pushed the bootstrap-token-authenticator branch from 02781a9 to 94b7a86 Compare February 14, 2017 19:31

ericchiang commented Feb 14, 2017

View reviewed changes

luxas reviewed Feb 14, 2017

View reviewed changes

ericchiang force-pushed the bootstrap-token-authenticator branch from 94b7a86 to 70fa725 Compare February 14, 2017 22:55

ericchiang changed the title ~~(WIP) apiserver: add a bootstrap token authenticator for TLS bootstrapping~~ kube-apiserver: add a bootstrap token authenticator for TLS bootstrapping Feb 14, 2017

ericchiang commented Feb 14, 2017

View reviewed changes

k8s-github-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Feb 21, 2017

ericchiang force-pushed the bootstrap-token-authenticator branch from 74e53ae to c5c237e Compare February 21, 2017 09:38

ericchiang commented Feb 21, 2017

View reviewed changes

sttts reviewed Feb 21, 2017

View reviewed changes

luxas approved these changes Feb 21, 2017

View reviewed changes

luxas reviewed Feb 21, 2017

View reviewed changes

kube-apiserver: add a bootstrap token authenticator for TLS bootstrap…

a0df658

…ping

ericchiang force-pushed the bootstrap-token-authenticator branch from c5c237e to a0df658 Compare February 21, 2017 16:45

ericchiang commented Feb 21, 2017

View reviewed changes

sttts reviewed Feb 21, 2017

View reviewed changes

jbeda approved these changes Feb 21, 2017

View reviewed changes

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 21, 2017

k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 21, 2017

jbeda mentioned this pull request Feb 22, 2017

Update bootstrap design doc with kubeadm UX kubernetes/community#381

Merged

k8s-github-robot merged commit 787b1a2 into kubernetes:master Feb 23, 2017

ericchiang deleted the bootstrap-token-authenticator branch February 23, 2017 16:42

ericchiang mentioned this pull request Feb 23, 2017

kube-apiserver: improve bootstrap token authentication error messages #41985

Merged

luxas mentioned this pull request Feb 24, 2017

Remove the kube-discovery binary from the tree #42070

Merged

kube-apiserver: add a bootstrap token authenticator for TLS bootstrapping #41281

kube-apiserver: add a bootstrap token authenticator for TLS bootstrapping #41281

Conversation

ericchiang commented Feb 11, 2017 • edited

k8s-reviewable commented Feb 11, 2017

luxas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sttts commented Feb 11, 2017

luxas commented Feb 14, 2017

ericchiang commented Feb 14, 2017

liggitt commented Feb 14, 2017

ericchiang commented Feb 14, 2017 • edited

deads2k commented Feb 14, 2017

ericchiang commented Feb 14, 2017 • edited

liggitt commented Feb 14, 2017

ncdc commented Feb 14, 2017

ericchiang commented Feb 14, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luxas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericchiang commented Feb 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luxas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericchiang commented Feb 21, 2017

Choose a reason for hiding this comment

jbeda left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbeda commented Feb 21, 2017

jbeda commented Feb 21, 2017

k8s-github-robot commented Feb 21, 2017

k8s-github-robot commented Feb 23, 2017

ericchiang commented Feb 11, 2017 •

edited

ericchiang commented Feb 14, 2017 •

edited

ericchiang commented Feb 14, 2017 •

edited