使用kubectl与kops 1.8创建AWS集群的权限及认证问题

Let's break down your questions one by one with practical commands and explanations tailored to your kops 1.8 setup:

1. Viewing Permissions for system:masters Group & kubecfg User, plus RBAC Validation #

First: Verify if RBAC is the default authorization mode #

kops 1.8 enables RBAC by default for AWS clusters, but you can confirm it in two ways:

• Check the kube-apiserver's startup arguments:

  # For a kops cluster, inspect the apiserver pod in kube-system namespace
  kubectl get pods -n kube-system | grep kube-apiserver
  kubectl describe pod <kube-apiserver-pod-name> -n kube-system | grep "authorization-mode"
  

  Look for --authorization-mode=RBAC (it may also include Node for node-specific authorization).
• Alternatively, check if the RBAC API is available:

  kubectl api-versions | grep rbac.authorization.k8s.io
  

  You should see rbac.authorization.k8s.io/v1 (stable in Kubernetes 1.8) or v1beta1.

Next: Inspect permissions for system:masters and kubecfg #

The system:masters group is automatically bound to the cluster-admin ClusterRole—this is a Kubernetes default that gives full cluster-wide admin access. To confirm this binding:

kubectl describe clusterrolebinding cluster-admin

Under the Subjects section, you'll see an entry like:

Subjects:
  Kind   Name            Namespace
  ----   ----            ---------
  Group  system:masters

Since your kubecfg user belongs to the system:masters group (from the certificate's O field), it inherits all cluster-admin permissions. To directly test what kubecfg can do:

kubectl auth can-i --as=kubecfg --all-namespaces '*' '*'

This will return yes, confirming full cluster access.

2. Missing kubecfg User in ~/.kube/config & Actual API User Identity #

Here's a key point to understand: the user entries in your kubeconfig are just friendly labels—Kubernetes doesn't use them for authentication. Instead, it relies on the X509 certificate's Subject fields (CN for username, O for groups) to identify the requester.

In your kops-created cluster, the admin user entry in ~/.kube/config uses a certificate where the Subject is O=system:masters, CN=kubecfg. Even though the kubeconfig labels it as admin, the API server sees the request as coming from the kubecfg user in the system:masters group.

To confirm this, you can decode the certificate data in your kubeconfig:

# Extract the client-certificate-data from your admin user entry, base64 decode it, save to a file
kubectl config view --raw -o jsonpath='{.users[?(@.name=="admin")].user.client-certificate-data}' | base64 -d > kubecfg-cert.pem

# Inspect the certificate's Subject
openssl x509 -in kubecfg-cert.pem -text -noout | grep Subject

You'll see the Subject line matching O=system:masters, CN=kubecfg—this is the actual identity the API server uses when you run kubectl commands.

Note: Kubernetes 1.8 doesn't include the kubectl whoami command (it was added later), but you can verify the identity by checking API server logs or using kubectl auth can-i with the --as flag as shown earlier.

3. tls: private key does not match public key Error & X509 Authentication Confirmation #

Yes, this error directly confirms two things:

1. Your cluster uses X509 client certificate authentication: The TLS layer is validating that your client certificate and private key are a matching pair before even passing the request to the API server for authorization.
2. You were using the kubecfg identity: The original client-certificate-data in your kubeconfig corresponds to the kubecfg user's certificate. When you modified this field, you replaced it with a certificate whose public key doesn't match the existing client-key-data (the private key for the original kubecfg certificate), hence the mismatch error.

To fix this, you'd need to update both client-certificate-data and client-key-data to a matching certificate/key pair if you want to use a different identity.

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