docs: improve documentation with MAX_EXPIRATION_SEC section

README.md

@@ -24,13 +24,21 @@ Certificates.
    `kubelet-csr-approver` will approve (or deny) depending on the deployment
    parameters you have set.
 
-The most important parameter that needs to be changed is the `PROVIDER_REGEX`
-environment variable: it lets you decide which hostnames can be approved or
-not. i.e., if all your nodes follow a naming convention (such as
-`node-randomstr1234.int.company.ch`), your regex could look like
-`^node-\w*\.int\.company\.ch$`
+### parameters
 
-It is also important to understand that the node DNS name needs to be
+The most important parameters (configurable through environment variables) that
+need to be changed are:
+
+* `PROVIDER_REGEX` lets you decide which hostnames can be approved or not\
+  e.g. if all your nodes follow a naming convention (say
+  `node-randomstr1234.int.company.ch`), your regex could look like
+  `^node-\w*\.int\.company\.ch$`
+* `MAX_EXPIRATION_SEC` permits to specify the maximum `expirationSeconds`
+  the kubelet can ask for.\
+  Per default it is hardcoded to a maximum of 368 days, and changing this environment
+  permits to reduce this value
+
+It is important to understand that the node DNS name needs to be
 resolvable for the `kubelet-csr-approver` to work properly. If this is an issue
 for you, please file an issue and I'll add a flag to disable this validation.
 
@@ -73,37 +81,39 @@ Taking inspiration from [Kubernetes built-in CSR
 approver](https://github.com/kubernetes/kubernetes/blob/v1.22.2/pkg/controller/certificates/approver/sarapprove.go),
 we check the following criteria:
 
-- the `CSR.Spec.SignerName` name must be `"kubernetes.io/kubelet-serving"`
-- the `CSR.Spec.Username` must be prefixed with `system:node:` (i.e. we only
+* `CSR.Spec.SignerName` must be `"kubernetes.io/kubelet-serving"`
+* `CSR.Spec.ExpirationSeconds`, if specified, must be smaller than `MAX_EXPIRATION_SEC`\
+  (the default value and hard-coded maximum for this controller is 368 days)
+* `CSR.Spec.Username` must be prefixed with `system:node:` (i.e. we only
   want to treat CSRs originating from the nodes themselves)
-- the CSR `CommonName` must be equal to the `CSR.Spec.Username`
-- the CSR DNS SubjectAlternativeNames (SAN) contains at most one entry
-- at least one SAN IP address or SAN DNS Name must be specified
-- the CSR SAN DNS Name (if specified) must comply with a provider-specific
+* x509 CR `CommonName` must be equal to the `CSR.Spec.Username`
+* CSR DNS SubjectAlternativeNames (SAN) contains at most one entry
+* at least one SAN IP address or SAN DNS Name must be specified
+* CSR SAN DNS Name (if specified) must comply with a provider-specific
   regex.
-- the CSR SAN DNS Name (if specified) must be prefixed with the node hostname
+* CSR SAN DNS Name (if specified) must be prefixed with the node hostname
   (where the hostname corresponds to `CSR.Spec.Username` trimmed of the
   `system:node:` prefix)
-- the CSR SAN IP Addresses must all be part of the set of IP addresses resolved
+* CSR SAN IP Addresses must all be part of the set of IP addresses resolved
   from the SAN DNS Name
-- ⚠ the CSR SAN DNS Name (if specified) must resolve to IP address(es) that
+* ⚠ the CSR SAN DNS Name (if specified) must resolve to IP address(es) that
   fall within the set of provider-specified IP ranges.
-- ⚠ the CSR SAN IP Address(es) must fall within a set of provider-specified IP
+* ⚠ the CSR SAN IP Address(es) must fall within a set of provider-specified IP
   ranges
 
 ⚠ == not yet implemented
 
 With those verifications in place, it makes it quite hard for an attacker to
 get a forged hostname to be signed, it would indeed require:
 
-- to impersonate a user on the Kubernetes API server with a `Username` that
+* to impersonate a user on the Kubernetes API server with a `Username` that
   prefixes the SAN DNS Name request. \ concretely, if the attacker wants to
   forge a CSR for the `auth.company.ch` domain, s/he would need to create a CSR
   with the username `system:node:a` (remember, we only check the that the DNS
   name is prefixed by the node name) \ it might then be possible to create a
   CSR from a node `a` (not a smart name for a node, I agree), or a node `auth`,
   already more plausible
-- to modify the provider-specific regex of the `kubelet-csr-approver` (requires
+* to modify the provider-specific regex of the `kubelet-csr-approver` (requires
   API access or direct access to the node where the controller is running). \
   however with API access, the attacker could as well also directly approve the
   CSR, and with full node access, the attacker could retrieve the controller's

cmd/kubelet-csr-approver/main.go

@@ -42,7 +42,7 @@ func main() {
 
 	flag.StringVar(&metricsAddr, "metrics-bind-address", ":8080", "The address the metric endpoint binds to.")
 	flag.StringVar(&probeAddr, "health-probe-bind-address", ":8081", "The address the probe endpoint binds to.")
-	flag.IntVar(&logLevel, "level", 0, "level ranges from -5 (Fatal) to 10 (MAX_EXPIRATION_SEC)")
+	flag.IntVar(&logLevel, "level", 0, "level ranges from -5 (Fatal) to 10 (Verbose)")
 	flag.Parse()
 
 	if logLevel < -5 || logLevel > 10 {