Change:
BUG REPORT: /kind bug /sig auth What happened: Kubernetes distro testing v1.12.0-rc.2 shows in setups with self-hosted control planes (i.e. apiserver, controller-manager, scheduler run as pods) that previously worked on v1.11.3 and prior, the kube-controller-manager now crash loops with: The kube-controller-manager is run with a with a to the default system ClusterRole , which seems to be defined at Editing the ClusterRole manually to add for was sufficient to fix the crash loop. What you expected to happen: I suspect a change between v1.11.3 and v1.12.0 release candidates altered kube-controller-manager to begin looking for configmap , but didn't update the ClusterRoles. How to reproduce it (as minimally and precisely as possible): Release candidate testing is happening in Anything else we need to know?: Environment: Kubernetes version (use kubectl version): v1.12.0-rc.2 Cloud provider or hardware configuration: GCE, DigitalOcean, AWS OS (e.g. from /etc/os-release): Container Linux 1855.4.0 Kernel (e.g. uname -a): 4.14.67-coreos Install tools: Typhoon
/sig cluster-lifecycle /area kubeadm /remove-sig auth edit: sorry, got this mixed up with another 1.12/1.11 issue. is this related to the secured controller manager work you did? /remove-sig cluster-lifecycle /sig auth /sig api-machinery
Those labels are not set on the issue: <detailsIn response to : /sig cluster-lifecycle /area kubeadm /remove-sig auth /sig auth /sig api-machinery Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
can you please try if works to skip that lookup?
we can make this non-fatal, compare
adding that flag to the controller-manager does also work to skip the lookup, without me manually editing the ClusterRole. Although if controller-manager defaults to looking up the configmap, I'd imagine the clusterrole should default to allowing configmap get's, no?
i was just checking if there's a work around we could suggest for 1.12 :) longer term, we can lean towards whatever and decide (adding to bootstrap policy vs making things non-fatal)
This seems like it should get a Known Issue comment in the release notes for 1.12. Can somebody please draft test and drop it in the known issues bucket issue ASAP?

Discussion:
eventsRule(), rbacv1helpers.NewRule("create").Groups(legacyGroup).Resources("endpoints", "secrets", "serviceaccounts").RuleOrDie(), rbacv1helpers.NewRule("delete").Groups(legacyGroup).Resources("secrets").RuleOrDie(), <del> rbacv1helpers.NewRule("get").Groups(legacyGroup).Resources("endpoints", "namespaces", "secrets", "serviceaccounts").RuleOrDie(), </del> <ins> rbacv1helpers.NewRule("get").Groups(legacyGroup).Resources("endpoints", "namespaces", "secrets", "serviceaccounts", "configmaps").RuleOrDie(), </ins> rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("endpoints", "secrets", "serviceaccounts").RuleOrDie(), // Needed to check API access.  These creates are non-mutating rbacv1helpers.NewRule("create").Groups(authenticationGroup).Resources("tokenreviews").RuleOrDie(),

- apiGroups: - "" resources: <ins> - configmaps </ins> - endpoints - namespaces - secrets