Configuring access for Kubectl to private GKE cluster
A guide to how to configure access for Kubectl to private Google Kubernetes Engine cluster with different level of restricted access
There are a handful of options to manage access to Spinnaker by third-party systems, without Spinnaker being exposed externally, this document will show you how to expose Spinnaker’s resources through AWS API Gateway which will help us monitor and restrict access to our exposed resources.
In this case we will expose a webhook URL to trigger a pipeline which could be called from a third-party system outside of our infrastructure, this document also assumes that you have configured Spinnaker in EKS.
First, we need to add a trigger to our pipeline, under Configuration, select Add Trigger and make its type selector Webhook, this will cause Spinnaker to expose an endpoint that must be hit in order to trigger the pipeline, for more information about configuring a webhook trigger check here .
Next, we can proceed in the creation of an API in AWS API Gateway, the main intention of this is to maintain security and control over Spinnaker’s exposed endpoints, and API Gateway offers an easy way to create, publish, maintain, monitor, and secure APIs at any scale.
You might notice after have deployed your API, that establishing a connection between AWS API Gateway to Spinnaker it’s not straight forward, this is mainly because API Gateway runs in its own VPC and is completely managed by AWS, removing the option of VPC peering between both networks.
Fortunately, with AWS API Gateway, you can do “Private Integrations”, which is a way to expose your HTTP/HTTPS resources behind an Amazon VPC for access by clients or third party systems outside of the VPC, currently only Network Load Balancers are supported to make private integrations.
Before create a Network load balancer, Let’s create a NodePort that opens a specific port on all worker nodes, and any traffic that is sent to this port will be forwarded to the Gate’s service.
apiVersion: v1 kind: Service metadata: name: spin-gate-internal namespace: <spinnaker's namespace> labels: app: spin cluster: spin-gate spec: type: NodePort selector: app: spin cluster: spin-gate ports: - name: http port: 8084 protocol: TCP
In addition to allow traffic through this port in AWS, we also need to add inbound rules to our EKS cluster’s Security Group.
Now, let create a Network load balancer in AWS, first select internal scheme, we don’t want expose all Gate’s endpoints, NLB supports TCP and TLS protocols, select TLS if you want to add a certificate from AWS Certificate Manager, it is important to create the NLB in the same VPC of your EKS Cluster.
After that, we are going to create a target group which is used to route requests to the registered instances in this group under the protocol and port that you specify, in this case we will use the NodePort created previously and register all EKS’s worker nodes.
Now, in API Gateway we can create a VpcLink to encapsulate connections between API Gateway and targeted VPC resources, just we need to select our NLB prior created.
At this point, we have our API Gateway with private integration to our private EKS cluster well configured, now just we need to add our webhook URL or other resources that we want to expose externally via API.
Now we can take advantage of all benefits that API Gateway offers in the moment to expose our resources, as access by IAM policies, api-keys, IP range, and more, without changing our EKS cluster’s network configuration.