2021-10-20

I am thrilled to share an exciting news here: Tanzu Mission Control now supports kubeconfig access for the following types of attached clusters:

• Amazon Elastic Kubernetes Service (EKS)
• Azure Kubernetes Service (AKS)
• Google Kubernetes Engine (GKE)

VMware CSP users can leverage this new capability to access these clusters. In this blog, I will show allow how a CSP user can get access to an AWS EKS cluster.

Pre-req

• An AWS EKS cluster
• The said cluster has been attached to Tanzu Mission Control
• You have admin permissions on the said cluster to update the Pinniped configuration.
• Assign a proper access to a CSP user or group. In my case, I assign a customised role (customrole02) to a CSP user: [email protected]

Step 1: Update the Pinniped configuration

Get the access to the AWS EKS cluster with AWS generated kubeconfig, remove [service.beta.kubernetes.io/aws-load-balancer-internal:](<http://service.beta.kubernetes.io/aws-load-balancer-internal:>) "true" from the spec.impersonationProxy.service.annotations . This change is to ask AWS to create a public load balancer.

dzhang@dzhang-virtual-machine:~$ kubectl edit credentialissuer cluster-auth-pinniped-config

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: config.concierge.pinniped.tmc.cloud.vmware.com/v1alpha1
kind: CredentialIssuer
metadata:
  creationTimestamp: "2021-10-21T04:40:15Z"
  generation: 1
  name: cluster-auth-pinniped-config
  resourceVersion: "3917"
  uid: 6381fdc9-a21c-40ca-b241-338ede51602d
spec:
  impersonationProxy:
    mode: auto
    service:
      annotations:
        networking.gke.io/load-balancer-type: Internal
        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "4000"
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
      type: LoadBalancer
status:
  strategies:
  - lastUpdateTime: "2021-10-21T04:40:21Z"
    message: could not find a healthy kube-controller-manager pod (0 candidates)
    reason: CouldNotFetchKey
    status: Error
    type: KubeClusterSigningCertificate
  - frontend:
      impersonationProxyInfo:
        certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJsekNDQVR5Z0F3SUJBZ0lRRnI5MVh5c28ycUVkdnNaL2pCSFVvakFLQmdncWhrak9QUVFEQWpBcU1TZ3cKSmdZRFZRUURFeDlRYVc1dWFYQmxaQ0JKYlhCbGNuTnZibUYwYVc5dUlGQnliM2g1SUVOQk1DQVhEVEl4TVRBeQpNVEEwTkRBeE1sb1lEekl4TWpFd09USTNNRFEwTURJeVdqQXFNU2d3SmdZRFZRUURFeDlRYVc1dWFYQmxaQ0JKCmJYQmxjbk52Ym1GMGFXOXVJRkJ5YjNoNUlFTkJNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUUKd3doa0NhOGRYUjVtZGNyNDZheHFFdjNiQnp1RUwvTHRzS2dXS0YxV1IrM1JaeExQWkN1ays0Slk4cVNtMVRESApuaTRUaTQ5MCtiOVpzd3IzTEJKQS9xTkNNRUF3RGdZRFZSMFBBUUgvQkFRREFnS0VNQjBHQTFVZEpRUVdNQlFHCkNDc0dBUVVGQndNQ0JnZ3JCZ0VGQlFjREFUQVBCZ05WSFJNQkFmOEVCVEFEQVFIL01Bb0dDQ3FHU000OUJBTUMKQTBrQU1FWUNJUURMN2xxQkxOTXk1d3ZuSDJOeksvZFl3OEsxNWE3OENNQkxweXJGQnp2dVpRSWhBSmNMREY2cwp5WUFpVkZjRWVNOGNWT1VXV3FpaGFCaDFYMUFMWjZpcjF4bnoKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        endpoint: <https://internal-a11c143c9c3f04b189cf56521270b881-750191297.us-west-2.elb.amazonaws.com>
      type: ImpersonationProxy
    lastUpdateTime: "2021-10-21T04:40:25Z"
    message: impersonation proxy is ready to accept client connections
    reason: Listening
    status: Success
    type: ImpersonationProxy
~

"/tmp/kubectl-edit-422064659.yaml" 38L, 2238C written

Step 2: Delete the exisiting private LB service so that the change made in Step 1 can kick in and create a new public load balancer

kubectl delete services -n vmware-system-tmc cluster-auth-pinniped-impersonation-proxy-load-balancer

We can see a new load balancer was created from the below

zhang@dzhang-virtual-machine:~$ k get svc -n vmware-system-tmc
NAME                                                      TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)         AGE
cluster-auth-pinniped-api                                 ClusterIP      172.20.103.112   <none>                                                                    443/TCP         8m44s
cluster-auth-pinniped-impersonation-proxy-load-balancer   LoadBalancer   172.20.197.155   a5c1f9c81a4a241c3abd84d4dbfxxxxx-1818796152.us-west-2.elb.amazonaws.com   443:31983/TCP   73s
cluster-auth-pinniped-proxy                               ClusterIP      172.20.109.227   <none>                                                                    443/TCP         8m43s
extension-manager-service                                 ClusterIP      172.20.58.9      <none>                                                                    443/TCP         9m8s
extension-updater                                         ClusterIP      172.20.240.51    <none>                                                                    9988/TCP        9m7s
gatekeeper-operator-service                               ClusterIP      172.20.149.56    <none>                                                                    443/TCP         8m42s
inspection-extension                                      ClusterIP      172.20.73.121    <none>                                                                    443/TCP         8m37s
policy-insight-extension-service                          ClusterIP      172.20.246.140   <none>                                                                    443/TCP         8m45s
policy-sync-extension                                     ClusterIP      172.20.48.162    <none>                                                                    443/TCP         8m40s

Also in AWS console: