Kubeadm: Enable the "root-ca-cert-publisher" controller?

[luxas]

I'm not sure what this controller does, but we might consider enabling it:

W1128 12:40:32.442846       1 controllermanager.go:508] Skipping "root-ca-cert-publisher"

@timothysc @sttts

[RA489]

@luxas still we need enabling root-ca-cert-publisher? I mean can you add some more info about the problem if it is left disabled

[chuckha]

@RA489 This issue is about learning what that controller actually does and figuring out if we should enable it or not. If you end up doing that research, please update this issue with your findings. Perhaps that will spark a discussion that could be brought up the kubeadm meeting to see if it's something we want/need.

[NicolasT]

FWIW, looking at the implementation (pointers below), this seems to be a controller which creates, in every namespace, a ConfigMap called kube-root-ca.crt which contains one key, ca.crt, whose value is supposed to be the certificate of the root CA used to sign kube-apiserver TLS server certs.

Code pointers:

• https://github.com/kubernetes/kubernetes/blob/e9212eba2fdad170c4a2016262efab1f51b5c4ae/cmd/kube-controller-manager/app/certificates.go#L127
• https://github.com/kubernetes/kubernetes/blob/e9212eba2fdad170c4a2016262efab1f51b5c4ae/pkg/controller/certificates/rootcacertpublisher/publisher.go

Introduced in https://github.com/kubernetes/kubernetes/commit/efac533f9269ca1687d084a7360f87f7b4ace1fc

Seems in turn related to the TokenRequest and TokenRequestProjection feature gates (where one needs access to a ConfigMap containing that CA cert in the Pod namespace in order to be able to 'project' the information as one would get from standard ServiceAccount injection in a container at some other place).

Whilst the usage of this feature seems like a corner-case to me (unless there's a plan to remove or replace/redesign default ServiceAccount injection?), it shouldn't harm to expose that CA certificate either by enabling this controller, it's 'public' information anyway.

[RA489]

I think it will not harm to expose that CA certificate if we enable this controller?

[NicolasT]

I think it will not harm to expose that CA certificate if we enable this controller?

No harm indeed, CA certificates should be 'ok for publication' by design, it's how X509 PKI works.

[luxas]

@kubernetes/sig-auth-feature-requests is this controller recommended to be on by default in v1.14?

[fabriziopandini]

@luxas
As kubeadm we are setting --controllers=*,bootstrapsigner,tokencleaner, and that means we are already enabling all on-by-default controllers. Is there anything on top of that we are expecting to do?

[timothysc]

@luxas why is this not enabled by default then?

[liggitt]

The controller is only started if the BoundServiceAccountTokenVolume feature gate is enabled:

https://github.com/kubernetes/kubernetes/blob/21bec91e895a828ee8ed8d45a7d58279b8cae46f/cmd/kube-controller-manager/app/certificates.go#L127-L130

That feature is still in alpha:
https://github.com/kubernetes/kubernetes/blob/21bec91e895a828ee8ed8d45a7d58279b8cae46f/pkg/features/kube_features.go#L493

I don't think there's anything to do here. I would not expect kubeadm to enable alpha features.

[timothysc]

thx for the update @liggitt

[astrieanna]

/remove-help since there's nothing to do.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[neolit123]

commenting on @NicolasT 's explanation:

Whilst the usage of this feature seems like a corner-case to me (unless there's a plan to remove or replace/redesign default ServiceAccount injection?), it shouldn't harm to expose that CA certificate either by enabling this controller, it's 'public' information anyway.

kubeadm is already exposing the cluster CA in the "cluster-info" ConfigMap.

@fabriziopandini

As kubeadm we are setting --controllers=*,bootstrapsigner,tokencleaner, and that means we are already enabling all on-by-default controllers. Is there anything on top of that we are expecting to do?

yes, if the controller graduates to be part of the defaults kubeadm will get it for free.

the BoundServiceAccountTokenVolume feature is still in alpha:
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/

/close

[k8s-ci-robot]

@neolit123: Closing this issue.

In response to this:

commenting on @NicolasT 's explanation:

Whilst the usage of this feature seems like a corner-case to me (unless there's a plan to remove or replace/redesign default ServiceAccount injection?), it shouldn't harm to expose that CA certificate either by enabling this controller, it's 'public' information anyway.

kubeadm already exposing the cluster CA in the cluster-info ConfigMap.

@fabriziopandini

As kubeadm we are setting --controllers=*,bootstrapsigner,tokencleaner, and that means we are already enabling all on-by-default controllers. Is there anything on top of that we are expecting to do?

yes, if the controller graduates to be part of the defaults kubeadm will get it for free.

the BoundServiceAccountTokenVolume feature is still in alpha:
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/

/close

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.