Openshift - configure_CSR_autoapproval

— ny_wk

In the fast-paced world of DevOps, anything that reduces manual toil is a blessing, `hai na`? When it comes to managing an OpenShift cluster, one of those often-overlooked yet critical tasks is the approval of Certificate Signing Requests, or CSRs. Every time a new node tries to join your OpenShift cluster, it sends a CSR to the Kubernetes API server, asking for a certificate to establish its identity. Manually approving these can be a real `pareshaani`, especially in large, dynamic setups. That’s where **OpenShift CSR auto-approval** comes in. It’s a powerful feature that automates this handshake, ensuring your nodes can onboard smoothly without human intervention. This setup is particularly relevant for **OpenShift 3.11 environments**, a version still prevalent in many enterprise `deta-centers` due to its stability. Let's `chai pe charcha` over how to implement this `jugaad` for a more efficient and less stressful OpenShift journey.

Why Automate OpenShift CSR Approval? The `Pareshaani` of Manual Certs

Imagine managing a cluster where nodes are scaling up and down frequently. Each new node needs a unique certificate issued by the cluster's certificate authority (CA) to securely communicate with the control plane. This is where CSRs come into play. A new node generates a private key and a CSR, sends it to the API server, and waits for approval. Once approved, the cluster CA signs the certificate, which the node then uses for authentication.

In a standard Kubernetes or OpenShift setup, this approval process can be manual. A cluster administrator would typically run `oc get csr` to list pending requests and then `oc adm certificate approve ` to approve them. While this offers granular control, it quickly becomes a bottleneck and a source of operational friction as your cluster grows or changes frequently. This manual step introduces delays, requires an admin to be constantly vigilant, and is prone to human error.

For instance, think about day-to-day operations: you've scaled up your application, and new worker nodes spin up. If the CSRs aren't approved promptly, these new nodes will remain in a "Not Ready" state, unable to accept workloads. This directly impacts application availability and responsiveness. This is where **OpenShift automatic certificate signing request approval** becomes not just a convenience, but a necessity for robust automation pipelines.

Beyond simple node onboarding, certificates are the backbone of secure communication within Kubernetes. Every pod, every service, every internal component uses certificates to verify identity. While the focus here is on node bootstrap certificates, understanding the broader context of **Kubernetes certificate management** is crucial. Automating the approval for nodes simplifies one of the foundational security layers, allowing DevOps teams to focus on higher-value tasks rather than routine approvals.

The solution we’re discussing, while specific to OpenShift 3.11, embodies a key principle of modern infrastructure management: if it's repetitive, automate it. Automating CSR approval ensures that your cluster scales gracefully, nodes join seamlessly, and your security posture remains strong without human intervention becoming a bottleneck. This is not just about convenience; it's about building a resilient, self-healing infrastructure. The manual process can be a source of errors, especially if an admin approves the wrong CSR or delays the process, leading to unexpected outages. An automated system, correctly configured, is both faster and more reliable.

Understanding the `Jugaad`: How OpenShift CSR Auto-Approval Works

So, how do we achieve this automation? The core idea is to deploy a special component within the OpenShift cluster that continuously monitors for new CSRs and approves them based on predefined rules. This "auto-approver" acts as a guardian, sifting through incoming requests and giving a green light to legitimate ones.

For OpenShift 3.11, the method involves deploying a set of Kubernetes resources – specifically, a `ClusterRole`, a `ServiceAccount`, a `ClusterRoleBinding`, and a `StatefulSet`. These components work together to:

1. Grant the necessary permissions to approve CSRs.
2. Provide an identity for the auto-approver process.
3. Run a long-running application (a Pod within a StatefulSet) that executes the approval logic.

The `autoapprover.yml` file is the blueprint for this entire system. It defines the permissions and the deployment strategy for our automated agent. Let's break down its components:

• ClusterRole (`system:node-bootstrap-autoapprover`): This grants the crucial permissions needed. Specifically, it allows the auto-approver to `get`, `list`, `watch`, `delete` CSRs, and, most importantly, `create` and `update` approval conditions on `certificatesigningrequests/approval`. Without these permissions, our auto-approver would be powerless.
• ServiceAccount (`bootstrap-autoapprover`): This provides an identity for our auto-approver Pod within the `openshift-infra` namespace. It’s like giving a specific ID card to our automated worker.
• ClusterRoleBinding (`bootstrap-autoapprover`): This links our `ServiceAccount` to the `ClusterRole`, effectively assigning the permissions defined in the ClusterRole to our ServiceAccount. This ensures that any Pod running with this ServiceAccount will inherit these elevated privileges.
• StatefulSet (`bootstrap-autoapprover`): This is where the magic happens. A StatefulSet is used to ensure the auto-approver Pod is always running and its state is maintained. Inside this StatefulSet, a Pod runs a container with a custom script.
• The Custom Script: This `bash` script, embedded within the StatefulSet's `command` and `args`, is the brain of our operation. It uses `oc observe csr` to continuously watch for new CSRs. When a CSR appears, the script evaluates it. It checks if the CSR's username matches specific patterns (e.g., `system:serviceaccount:openshift-infra:node-bootstrapper` or `system:node:*`), which are characteristic of legitimate node bootstrap requests. If the conditions are met and the CSR is pending, it executes `oc adm certificate approve` to approve it. Additionally, the script includes logic to delete expired certificates, which is a neat cleanup feature.
• ImageStreamTag (`node:v3.11`): This ensures that the auto-approver container uses the correct OpenShift node image as its base, providing the necessary `oc` binaries and other tools needed by the script. This image comes from an internal OpenShift registry (or an external one as configured), like `artifactorycn.ORG.com:17011/openshift/node:v3.11.0` in the example source.

It's important to highlight the version limitation: this particular `jugaad` is explicitly designed for **OpenShift cluster's version 3.11**. While the core concepts of CSR management persist across versions, the exact implementation details, especially the underlying base image and potentially the `oc` command behavior, might differ in newer OpenShift 4.x releases. Always verify compatibility if you're adapting this to a different cluster version.

The security implications are paramount here. By granting a ServiceAccount the power to approve certificates, you are essentially giving it significant control over your cluster's trust network. Therefore, the approval logic in the embedded script is critical. It must be stringent enough to only approve legitimate node requests and nothing else. The provided script wisely focuses on `system:node:` and specific bootstrapper service accounts, which are strong indicators of genuine node onboarding attempts.

Implementing OpenShift CSR Auto-Approval: Step-by-Step `Amal`

Alright, `ab time aa gaya hai` to get our hands dirty and implement this. Before we begin, make sure you meet the prerequisites:

• You must have **cluster admin rights** on your OpenShift 3.11 cluster.
• You need to be logged into the cluster via `oc CLI` or the web console.
• Your OpenShift cluster version must be **3.11**.

Option 1: During Cluster Installation (Bootstrap)

If you're setting up a new OpenShift 3.11 cluster from scratch, you can enable auto-approval right from the beginning. This is the cleanest way to do it. You simply need to add a special variable to your Ansible inventory file (`hosts` file, typically) used during the installation:

openshift_master_bootstrap_auto_approve=true

This variable is well-documented in the official OpenShift 3.11 documentation and tells the installer to set up the necessary components automatically. However, for existing clusters, we need the post-installation approach.

Option 2: Post-Installation (Applying `autoapprover.yml`)

This is the scenario where you have an existing OpenShift 3.11 cluster and want to add auto-approval. This is what the video and the source YAML primarily address. You'll apply a YAML file that defines all the necessary Kubernetes resources.

Step 1: Obtain the `autoapprover.yml` Content

The core of our solution is the YAML file. Let's reconstruct it and understand each part.

kind: ClusterRole
apiVersion: v1
metadata:
  name: system:node-bootstrap-autoapprover
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - delete
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/approval
  verbs:
  - create
  - update
---
kind: ServiceAccount
apiVersion: v1
metadata:
  name: bootstrap-autoapprover
  namespace: openshift-infra
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bootstrap-autoapprover
roleRef:
  kind: ClusterRole
  name: system:node-bootstrap-autoapprover
subjects:
- kind: User
  name: system:serviceaccount:openshift-infra:bootstrap-autoapprover
  apiVersion: rbac.authorization.k8s.io/v1
---
kind: StatefulSet
apiVersion: apps/v1beta1
metadata:
  name: bootstrap-autoapprover
  namespace: openshift-infra
  annotations:
    # This annotation allows the image to be automatically updated if the ImageStreamTag changes
    image.openshift.io/triggers: |
      [ { "from" : { "kind" : "ImageStreamTag" , "name" : "node:v3.11" } , "fieldPath" : "spec.template.spec.containers[?(@.name==\"signer\")].image" } ]
spec:
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: bootstrap-autoapprover
    spec:
      # The auto-approver typically runs on master nodes to ensure high availability and access to critical APIs
      nodeSelector:
        node-role.kubernetes.io/master: 'true'
      serviceAccountName: bootstrap-autoapprover
      terminationGracePeriodSeconds: 1
      containers:
      - name: signer
        image: " " # Image will be populated by the ImageStreamTag trigger
        command:
        - /bin/bash
        - -c
        args:
        - |
          #!/bin/bash
          set -o errexit
          set -o nounset
          set -o pipefail

          unset KUBECONFIG # Ensure the script uses the in-cluster service account credentials
          cat <