K8S获取ConfigMap数据问题：禁用ServiceAccountToken自动挂载后的解决方案咨询

Let’s break down your problem into two clear parts: resolving the token not found error when automountServiceAccountToken: false is set, and finding a reliable way to inject specific environment variables across all pods in every namespace.

Fixing the "open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory" Error #

This error pops up because client-go defaults to loading the ServiceAccount token from the standard in-cluster path, which doesn’t exist when automount is disabled. Since you can’t modify the problematic pod configurations, here are actionable code-level workarounds:

1. Add a Fallback Configuration in Your Go Code #

Modify your client-go logic to handle in-cluster config failures gracefully, using alternative authentication sources like environment variables. Here’s a practical snippet:

import (
    "fmt"
    "os"
    "encoding/base64"
    "k8s.io/client-go/rest"
    "k8s.io/client-go/kubernetes"
)

func getKubernetesConfig() (*rest.Config, error) {
    // First attempt to use in-cluster config
    config, err := rest.InClusterConfig()
    if err == nil {
        return config, nil
    }

    // Fallback to custom environment variables if in-cluster fails
    apiServer := os.Getenv("CUSTOM_KUBE_API_SERVER")
    bearerToken := os.Getenv("CUSTOM_KUBE_TOKEN")
    caCertBase64 := os.Getenv("CUSTOM_KUBE_CA_CERT")

    if apiServer == "" || bearerToken == "" || caCertBase64 == "" {
        return nil, fmt.Errorf("no valid Kubernetes configuration found: in-cluster failed and no env vars provided")
    }

    // Decode base64 CA certificate
    caCertData, err := base64.StdEncoding.DecodeString(caCertBase64)
    if err != nil {
        return nil, fmt.Errorf("failed to decode CA cert: %v", err)
    }

    // Build manual config from env vars
    return &rest.Config{
        Host:            apiServer,
        BearerToken:     bearerToken,
        TLSClientConfig: rest.TLSClientConfig{CAData: caCertData},
    }, nil
}

// Initialize the client set with the fallback config
func main() {
    config, err := getKubernetesConfig()
    if err != nil {
        panic(err.Error())
    }
    clientset, err := kubernetes.NewForConfig(config)
    if err != nil {
        panic(err.Error())
    }
    // Use clientset to access your ConfigMap...
}

This way, if the in-cluster token path doesn’t exist, your app will use the credentials provided via environment variables instead.

2. Manual Secret Mount (If Pod Modifications Are Allowed for Some Cases) #

If you can modify certain pod configurations (even if not all), you can manually mount the target ServiceAccount’s secret to the expected path:

• Create a ServiceAccount with permissions to read your specific ConfigMap
• Retrieve the auto-generated secret linked to this ServiceAccount (it contains the token and CA certificate)
• Add a volume and volume mount to the pod spec:

volumes:
  - name: sa-secret
    secret:
      secretName: <your-serviceaccount-secret-name>
volumeMounts:
  - name: sa-secret
    mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    readOnly: true

This replicates the auto-mounted ServiceAccount setup without enabling automountServiceAccountToken.

Injecting Specific Environment Variables Across All Pods in All Namespaces #

Kubernetes doesn’t have a native "global environment variable" feature, but these are the most robust alternatives:

1. Mutating Admission Webhook #

This is the most flexible and scalable solution. A mutating webhook intercepts pod creation requests before they’re persisted, modifies the pod spec to add your desired environment variables, and sends the updated spec back to the API server.

• You can configure the webhook to target all pods across all namespaces using admission rules
• Official Kubernetes SDKs simplify building these webhooks, handling the core logic of intercepting and modifying pod specs
• Once deployed, it automatically injects env vars into every new pod, regardless of how the pod is created.

2. GitOps Tooling (If Using Infrastructure as Code) #

If you manage all your workloads with GitOps tools like Argo CD or Flux, you can define a base template that includes your environment variables. All workloads can inherit this template, ensuring consistent env var injection across your cluster. This only covers workloads managed by the tool, but it’s a clean approach for GitOps-based environments.

3. Namespace-Level Bases (Limited Scope) #

For individual namespaces, you can use Kustomize bases or Helm charts to define default environment variables that all pods in the namespace inherit. This isn’t cluster-wide, but it’s useful if you need granular control per namespace.

内容的提问来源于stack exchange，提问作者Jenny M