Security & compliance — N1 IT Landscape

N1 IT Landscape — The Blueprint · CF-Access internal

Security & compliance

N1 IT Landscape · Owner: Arun Venkataraman · source of truth: markdown SSOT

N1 IT Landscape — Security & compliance setup

CURRENT-STATE as of 2026-06-09 · part of the N1 IT Landscape (start at Overview). Owner: Arun Venkataraman (Principal Engineer).

The security and compliance posture in one place — the controls exactly as configured, for a HIPAA platform handling patient data.

17. SECURITY & COMPLIANCE SETUP

N1 is a HIPAA platform handling patient PHI. The security model is identity-first and default-deny. This section describes the controls exactly as they are configured.

17.1 Network boundary

All application inbound traffic enters through Cloudflare Tunnels only. There are no public IPs on workloads, no public application endpoints, no load balancers, and no ACM certificates; all subnets are private; TLS terminates at Cloudflare.
The EKS Kubernetes API-server endpoints are public (endpoint public access = Yes) and authenticated by AWS IAM/OIDC — used by kubectl, ArgoCD, Karpenter and CI.
Internet egress is via one NAT gateway per cluster VPC (both in us-east-2a).

17.2 Identity & access

Google Workspace is the single identity provider. Cloudflare WARP is always-on; every internal app sits behind Cloudflare Access (Google sign-in, @n1.healthcare). 2FA is mandatory (YubiKeys onsite; YubiKey or Authenticator remote) and enforced on GitHub.
Dashlane holds staff credentials and is not linked to Google.
Developer API/service keys are self-service via Slack, expire in 30 days , and existing keys are invalidated when a new one is issued.

17.3 Source control & CI/CD controls

GitHub rulesets (org-wide) require ≥1 PR approval, block force-push and deletion on main/develop, and require signed commits on every branch of every repo (see §7.4).
CI uses GitHub OIDC role assumption (no long-lived AWS keys), SHA-pinned third-party actions, safe-chain supply-chain shims on dependency installs, and Grype CVE scans on the production build path.
The enforced “N1 Default “ GitHub code-security config has secret-scanning, push-protection and code-scanning disabled — these GitHub Advanced Security features are not offered on the Team plan (Dependabot alerts/updates remain on). The org Actions policy is all and members can create repos.
The github-action-deployment-approval (human approve/reject) step is wired into admin-dashboard but commented out of the shared bastion/deploy.yml, so most production deploys have no CI approval gate. Production deploys are restricted to Arun, Darpan, Jasper.

17.4 Data, secrets & encryption

Each service has its own Aurora database in a dedicated, peered “database” VPC; the Aurora clusters are provisioned manually (not in Terraform).
Secrets live in AWS Secrets Manager and reach pods via External Secrets Operator — never in images or manifests.
Encryption at rest: customer-managed KMS keys for EKS etcd envelope encryption; AWS-managed keys for RDS, S3 and Secrets Manager. All S3 buckets have full public-access block.
Developers reach read-only staging DB/Redis only over WARP via Cloudflare Gateway private DNS (db.staging.n1 / redis.staging.n1).

17.5 Edge protection

n1.care (Cloudflare Pro) runs the full managed WAF (Cloudflare Managed + OWASP Core rulesets, exposed-credentials check, normalization, L7 DDoS). n1-research.com (Free) has the Free managed ruleset + normalization + L7 DDoS, and relies primarily on Cloudflare Access for internal services.

17.6 Observability

OpenTelemetry → SigNoz (with Slack alerting) in both clusters; Langfuse captures LLM traces for the AI services. Base/tool images come from Docker Hardened Images (dhi.io), mirrored into ECR via pull-through cache.