Change:
The command only has Cobra (CLI) documentation and there are no pointers on what fields are relevant in the configuration passed with --config to it: Add a minimal example + config for the command usage on this page: /sig cluster-lifecycle /kind feature xref
/triage accepted
/language en

Discussion:
`kubeadm kubeconfig` provides utilities for managing kubeconfig files. <ins> For examples on how to use `kubeadm kubeconfig user` see [Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users). </ins> ## kubeadm kubeconfig {#cmd-kubeconfig} {{< tabs name="tab-kubeconfig" >}}

Kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`. `system:masters` is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC). Do not share the `admin.conf` file with anyone and instead grant users custom permissions by generating <del> them a kubeconfig file using the `kubeadm kubeconfig user` command. </del> <ins> them a kubeconfig file using the `kubeadm kubeconfig user` command. For more details see [Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users). </ins> {{< /warning >}} Make a record of the `kubeadm join` command that `kubeadm init` outputs. You

nodes` when run on the control-plane node. {{< note >}} <del> As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run on the first control-plane node. To provide higher availability, please rebalance the CoreDNS Pods </del> <ins> As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run on the first control-plane node. To provide higher availability, please rebalance the CoreDNS Pods </ins> with `kubectl -n kube-system rollout restart deployment coredns` after at least one new node is joined. {{< /note >}}

{{< feature-state for_k8s_version="v1.15" state="stable" >}} <del> Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. </del> <ins> Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. It also covers other tasks related to kubeadm certificate management. </ins> ## {{% heading "prerequisites" %}}

You can renew your certificates manually at any time with the `kubeadm certs renew` command. <del> This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. </del> <ins> This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. </ins> After running the command you should restart the control plane Pods. This is required since dynamic certificate reload is currently not supported for all components and certificates. [Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet and not by the API Server, thus kubectl cannot be used to delete and restart them. <del> To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` </del> <ins> To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` </ins> and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/). The kubelet will terminate the Pod if it's no longer in the manifest directory. You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate

in the CSR but also verifies the requested IPs and domain names. This would prevent a malicious actor that has access to a kubelet client certificate to create CSRs requesting serving certificates for any IP or domain name. <ins> ## Generating kubeconfig files for additional users {#kubeconfig-additional-users} During cluster creation, kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`. [`system:masters`](/docs/reference/access-authn-authz/rbac/#user-facing-roles) is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC). Sharing the `admin.conf` with additional users is **not recommended**! Instead, you can use the [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig) command to generate kubeconfig files for additional users. The command accepts a mixture of command line flags and [kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) options. The generated kubeconfig will be written to stdout and can be piped to a file using `kubeadm kubeconfig user ... > somefile.conf`. Example configuration file that can be used with `--config`: ```yaml # example.yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration # Will be used as the target "cluster" in the kubeconfig clusterName: "kubernetes" # Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig controlPlaneEndpoint: "some-dns-address:6443" # The cluster CA key and certificate will be loaded from this local directory certificatesDir: "/etc/kubernetes/pki" ``` Make sure that these settings match the desired target cluster settings. To see the settings of an existing cluster use: ```shell kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}" ``` The following example will generate a kubeconfig file with credentials valid for 24 hours for a new user `johndoe` that is part of the `appdevs` group: ```shell kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h ``` The following example will generate a kubeconfig file with administrator credentials valid for 1 week: ```shell kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h ``` </ins>