Safety

Zero Trust Architecture

Never trusting any request by default, regardless of network location, verify every access explicitly.

Overview

Zero Trust is a security model that eliminates implicit trust based on network location. "Never trust, always verify": every request is authenticated and authorised regardless of whether it originates from inside or outside the network perimeter. The model was introduced by John Kindervag (Forrester Research, 2010) and operationalised in Google's BeyondCorp (2014). It requires strong identity, device validation, micro-segmentation, and least-privilege access.

Origin

John Kindervag coined "Zero Trust" at Forrester Research in 2010. Google published "BeyondCorp: A New Approach to Enterprise Security" (2014) documenting their transition from VPN to identity-based access, eliminating the privileged corporate network. NIST published SP 800-207 (Zero Trust Architecture, 2020) as the authoritative federal guidance. The Biden Executive Order 14028 (2021) mandated zero trust for federal agencies.

Examples

Service-to-service mTLS authentication in TypeScript

import https from 'https';
import fs from 'fs';
import fetch from 'node-fetch';

// Each service has a client certificate signed by the internal CA
const mtlsAgent = new https.Agent({
  cert: fs.readFileSync('/run/secrets/client-cert.pem'),
  key: fs.readFileSync('/run/secrets/client-key.pem'),
  ca: fs.readFileSync('/run/secrets/internal-ca.pem'),
  rejectUnauthorized: true, // Require valid cert from peer
});

// All internal service calls use mTLS; no bearer tokens needed
async function callInventoryService(productId: string) {
  const response = await fetch(
    'https://inventory.internal/products/' + productId,
    { agent: mtlsAgent }
  );
  if (!response.ok) throw new Error('Inventory call failed: ' + response.status);
  return response.json();
}

// Server-side: verify client certificate subject
import tls from 'tls';
function verifyServiceIdentity(socket: tls.TLSSocket): string | null {
  const cert = socket.getPeerCertificate();
  if (!cert || !socket.authorized) return null;
  return cert.subject?.CN ?? null; // e.g., "order-service"
}

mTLS means both parties present certificates; the server verifies the client certificate against the internal CA, and the client verifies the server certificate. A compromised service cannot impersonate another service without its private key. Certificate rotation should be automated via cert-manager (Kubernetes).

Zero-trust policy enforcement with OPA (Open Policy Agent) in Ruby

require 'net/http'
require 'json'

class PolicyEngine
  OPA_URL = URI('http://opa.internal:8181/v1/data/authz/allow')

  def self.authorize!(request_context)
    result = query_opa(request_context)
    unless result['result'] == true
      raise AuthorizationError, "Policy denied: #{request_context.inspect}"
    end
  end

  def self.query_opa(context)
    http = Net::HTTP.new(OPA_URL.host, OPA_URL.port)
    req = Net::HTTP::Post.new(OPA_URL.path, 'Content-Type' => 'application/json')
    req.body = { input: context }.to_json
    response = http.request(req)
    JSON.parse(response.body)
  end
end

# In controller before_action:
before_action :enforce_policy

def enforce_policy
  PolicyEngine.authorize!(
    user: {
      id: current_user.id,
      roles: current_user.roles,
      department: current_user.department
    },
    resource: { type: 'order', id: params[:id] },
    action: request.method.downcase,
    environment: {
      ip: request.remote_ip,
      time: Time.current.iso8601
    }
  )
end

OPA (Open Policy Agent) evaluates Rego policies that combine user attributes, resource attributes, and environmental context. Centralising policy in OPA means changing an access rule does not require redeploying the application; the new Rego policy is pushed to OPA independently.

Use Cases

01Remote and distributed workforces where the corporate network perimeter is meaningless; employees access systems from personal devices over home networks
02Multi-cloud and hybrid environments where resources span AWS, GCP, Azure, and on-premises with no single network boundary
03Microservice architectures where east-west traffic (service-to-service) was previously implicitly trusted within the cluster
04Contractor and third-party access where granting VPN access to the entire network is excessive; device-aware, identity-aware proxies grant access to specific applications only

When Not to Use

//Do not apply zero-trust controls to systems that cannot perform continuous authentication (old industrial control systems, legacy devices without TLS support)
//Do not implement zero trust incrementally in a way that creates hybrid trust zones; partial zero trust can give a false sense of security while leaving significant attack surface
//Zero trust does not replace defence-in-depth; network segmentation, encryption, and vulnerability management remain necessary alongside identity verification

Technical Notes

Google BeyondCorp's access proxy evaluates device certificate (is this a managed device?), user identity (who is logged in?), and access policy (is this user allowed this resource?) for each request
SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment) provide workload identity in Kubernetes; each pod receives a short-lived X.509 certificate identifying the service, used for mTLS
Istio service mesh (Kubernetes) enforces mTLS between pods by injecting Envoy sidecar proxies that handle certificate lifecycle automatically; AuthorizationPolicy objects define which services can call which endpoints
Continuous validation means re-evaluating access mid-session: detecting device compliance change, identity anomaly (impossible travel, unusual API access patterns), or token revocation. Google BeyondCorp Enterprise re-evaluates access every few minutes