June 2022 Summaries

### Zero Trust Network Access (ZTNA) is a framework for providing secure access in today's decentralized network ecosystem. It removes the inherent trust in networks, resources, devices, and users, instead adopting a three-core principle-based approach: Assume breach, Verify explicitly, and Least privileged access. ZTNA solutions deny all access requests by default until trust can be established, requiring explicit verification from every user, regardless of their position within the organization. This approach provides granular control over which resources users may access and under which contexts. With ZTNA, businesses can unify access control across a single system, simplify policy enforcement, and reduce administrative overhead. However, deploying and managing Zero Trust security architectures introduces new complexities, particularly for DevSecOps deployments. Automation is essential to streamline development, deployment, and management of IT infrastructures, but integrating granular access control policies into tools requires constant care and feeding. Twingate's secure access solution was designed from the start to deliver enterprise-class Zero Trust Network Access with consumer-grade usability, allowing customers to deploy ZTNA globally in as little as fifteen minutes.

Cybersecurity is a complex and dynamic field that requires a collective defensive posture to better prepare and respond faster when a breach occurs. The RSA Conference highlighted the importance of Zero Trust, which aims to eliminate implicit trust by verifying identity, device, access, and service through a structured approach. However, this philosophy still faces challenges, such as the lack of clarity around its definition and skepticism from some attendees. To address these concerns, a multi-layered approach is recommended, including monitoring traffic, implementing static and dynamic code analysis, verifying vendors, and downloading open-source libraries. The conference also emphasized the need to protect data at rest in DevOps environments, where sensitive information often resides in non-production environments. Ultimately, cybersecurity requires a team effort from governments, private sectors, and individuals to foster collaboration and win the battle against cyber threats.

Twingate is a solution that provides simple and secure access to Kubernetes APIs and services running within clusters. It offers the option of deploying outside of the cluster, which can limit both inbound and outbound communications by removing exposure to the public API. This approach is considered more secure than traditional VPNs and can be rapidly implemented. To get started, one must have a Twingate account, install the client, and set up their network. The guide assumes users have a private Kubernetes cluster setup with access via an alternative connection, Azure CLI/ AWS CLI/Google CLI installed, and Kubectl installed. It does not utilize advanced deployment techniques like Terraform or Pulumi.

Device posture plays a crucial role in Zero Trust Network Architectures (ZTNA) as it provides critical context for any least-privileged authorization decision. The state of a device's security features, such as firewall status or OS version, is essential to determine whether to authorize access to protected resources. Traditional approaches to secure access have become less effective due to the dynamic nature of user devices and the increasing number of unmanaged endpoints. Device posture checks must be part of every access request, especially when more devices are owned by users, contractors, and third parties. Twingate's Zero Trust solution is uniquely positioned to unify device posture checks within a single, easily-managed system, providing a straightforward way to create and enforce granular least-privilege-access policies on every user device.

This guide provides a step-by-step process for deploying Twingate to Google Kubernetes Engine (GKE) using Google Cloud Platform (GCP). The deployment involves creating a new subnet, setting up the Twingate connector container, and configuring the connection to the Kubernetes private endpoint. The process requires additional resources that will incur costs, so users should note this before proceeding. The guide assumes prior knowledge of deploying a private GKE cluster and provides recommendations for adapting the gcloud command to suit individual environments. By following this guide, users can establish secure access to their private Kubernetes API using Twingate.

This guide provides a step-by-step process for deploying Twingate to AWS EKS (Elastic Container Service for Kubernetes). The deployment involves creating a connector, deploying the connector to AWS ECS (Fargate), and adding an EKS resource to Twingate. The process requires several steps, including generating tokens, creating a task definition file, registering the task definition with AWS ECS, and launching the connector as a Fargate service. Once the deployment is complete, the Twingate admin portal will show the connector as connected, allowing users to access their private Kubernetes API without requiring public access. The guide assumes that the reader has already deployed a private EKS cluster and has an AWS subscription.

This guide provides a step-by-step process for deploying Twingate to an Azure Kubernetes Service (AKS) cluster. To start, create a new subnet within the AKS cluster vnet using Azure CLI, specifying the resource group and address prefix values. Then, deploy the Twingate connector by creating a new network page in the Twingate admin console, selecting "Azure" as the deployment method, and customizing the command to specify the container deployment details. The guide also covers adding the Kubernetes private endpoint as a resource that the connector can communicate with, testing the connection, and verifying secure access to the Kubernetes API without public access. The process assumes an existing AKS cluster and may incur additional costs for Azure resources.