Northflank

Platform
Use cases
Resources
Case studies
Pricing

Security

Northflank Ltd
20-22 Wenlock Road, London, England, N1 7GU
Company Number: 11918540
VAT: GB334718301

Company location: United Kingdom, London
Contact: security@northflank.com, services@northflank.com
ICO Data Protection Officer: William James Stewart, will@northflank.com

Northflank is a developer platform. The core offering is a cloud service. Customers choose between two deployment models. The first is a multi-tenant PaaS deployment model where workloads run in Northflank’s Kubernetes clusters on Google Cloud. The second is a Bring Your Own Cloud (BYOC) deployment model where workloads run on the customer's own cloud account, VPC, and Kubernetes cluster. Northflank provides a higher-level abstraction to Kubernetes as a workload platform. This promotes faster and simpler deployment of workloads to Kubernetes and CSPs.

Northflank’s core features include

  • Deploy services, jobs, and databases
  • Integration with GitHub, Bitbucket, and GitLab
  • Integration with AWS, GCP, Azure, and Civo
  • Integration with external container registries
  • Preview environments, staging, and production environments
  • Improved DX through the Northflank real-time UI, API, CLI, GitOps, and Templates
  • Bi-directional Northflank UI, templates and Gitops
  • Manage, orchestrate, and full lifecycle management of Kubernetes clusters
  • Create continuous integration, deployment, and delivery workflows
  • Observability with health-checks, logs, and metrics
  • Disaster Recovery
  • Secure Multi-tenancy
  • Organisation, Team, and RBAC controls
  • Custom domains and SSL certificate management

Northflank’s use cases

  • Workload Platform
  • Developer Platform
  • Internal Developer Platform (IDP)
  • Cloud platform
  • Replacement for AWS EB, AWS ECS, Heroku, Cloud Run
  • Replacement for Terraform, Pulumi, ArgoCD
  • Replacement for Jenkins, GitHub Actions, Drone, GitLab CI, CircleCI
  • Replacement for Spinnaker, Cloud Foundry, Harness, Octopus Deploy, Codefresh
  • Application platform for Kubernetes, OpenShift, Tanzu, and other K8s distributions

  • Northflank control plane: Google Cloud London or Google Cloud Amsterdam
  • Northflank worker clusters:
    • Free: Multiple Azure Locations - user selected
    • Paid: Multiple GCP Locations - user selected
  • BYOC: Running in the user’s own cloud account managed by Northflank

Types of data

  • Metadata, control-plane data: Northflank hosted
  • Workload runtime and data: BYOC
  • Logs and metrics: Northflank hosted or BYOC
    • If generated logs from user workloads are PII we recommend using BYOC for logs
  • Builds and images: Northflank hosted or BYOC
  • DNS: Northflank hosted via NS1 or BYO
  • Backups:
    • Snapshots: BYOC
    • Dumps: Northflank S3
    • Global Backups: User-controlled S3

Compliance

  • SOC2 Type 1: No
  • SOC2 Type 2: No
  • HIPAA: No
  • ISO 27001/27018: No

Whilst Northflank doesn’t currently hold any certificates the platform has been built from top to bottom with security in mind. Northflank is currently contractually obliged to support SOC2 within the next year and has on-boarded on to the Vanta platform. In addition, we are contractually obliged to begin annual penetration tests over the next year.

Northflank has not experienced a security breach since the company's formation on April 1st, 2019.

Platform

Organisation

  • Organisations allow centralised user management, while providing different teams the option of their own access control and resource management.
  • OIDC/SAML
    • Organisation members can log in using Single Sign On (SSO) / SAML integration / OIDC integration with client’s Identity Provider (IdP).
    • Users can be provisioned and have roles managed using SCIM / Directory Sync / LDAP integration through JIT or SCIM.
    • Organisation members can be restricted to only sign in via SSO.
    • SSO users can require approval from an existing user with an admin permission before accessing their application.
    • Single Sign On is included as part of our enterprise offering.
  • Organisation admins can configure maximum session time for users as well as requiring 2FA to be enabled.

DDOS Protection

  • Northflank leverages Enterprise Cloud Armour in all Google Cloud regions. This helps to mitigate the control-plane and Northflank-managed worker clusters from DDOS attack.

RBAC

  • RBAC gives user access control on the organisation, team, and project level
  • Users may be restricted to specific teams based on their role and prevented from accessing organisation settings
  • Users may be restricted to specific projects based on their role and prevented from accessing team settings
  • RBAC roles may be automatically assigned/removed based on the linked identity provider groups on the organisation level.

API Access

  • API access can be separately controlled via API roles which allow similar scoping capabilities as RBAC roles
  • API tokens are managed on a team level, with API roles being assignable on the organisation and team levels
  • API roles may be automatically assigned/removed based on the identity provider groups on the organisation level

Disaster Recovery

  • Disk snapshots (provided by the cloud provider) can be taken against stateful workloads
  • Dump-type backups that extract data through an application-level dump tool. This is compressed and stored in a private Northflank-owned storage bucket. Accessing data for backups and restores is provided through pre-signed URLs that are valid for one hour
  • Global backups export disk snapshots to user-provided S3-compatible storage services
    • The data is uploaded/restored within the cluster
    • The backup data in S3 is encrypted through AES256-GCM-HMAC-SHA256

Certificates

  • Northflank uses Let’s Encrypt to automatically issue SSL certificates for domains and stateful workloads requiring SSL certificates. Northflank provisioned Certificates regenerate automatically before expiry.
    • Alternatively, domains support importing user-managed certificates, which makes certificate management the user’s responsibility
  • Northflank maintains wildcard certificates for the code.run domain, which is used for default generated public port DNS entries
  • Northflank adds *.code.run and other relevant domains to the Public Suffix List to defend against cross-site cookie attacks and to enable unlimited rate limits for Let’s Encrypt generation

External Secret Managers

  • It is possible to defer storage of secrets to external providers such that secrets are not stored in Northflank’s database. This feature is currently in beta.

Image Scanning

  • Snyk is used to monitor, notify, and create automatic pull requests to fix vulnerabilities in the Northflank code-base packages and Dockerfiles

Approval Flow

  • Changes made to resources via Northflank’s template system / Infrastructure as Code can be made to require approval from a user with a specific permission or leverage approval policies from existing version control systems.

Networking

  • Services and addons can communicate over private networking within the cluster
  • Services and addons do not need to be exposed publicly
  • Addons by default have TLS enabled during the creation flow
  • Access to private services within the cluster can be achieved through the Northflank CLI port-forward or Tailscale

Tailscale VPN

  • The Northflank platform has support for accessing services in-cluster via Tailscale or providing service access to resources in a Tailscale network
  • Service access to resources within an existing Tailnet deploys Tailscale as a sidecar per service/job/build
    • It is possible to restrict which services have access to a Tailscale network through tags, and services without the tag assigned will not deploy the Tailscale sidecar

Egress IP Gateways

  • Northflank PaaS has support for static egress IPs provided by Cilium
    • The IPs can be either multi-tenant (shared with multiple users in the region) or allocated specifically for teams/projects per region
  • BYOC egress IPs are provided by cloud-provider NAT gateways or equivalent where possible

Upgrades

  • The Northflank platform sees regular upgrades, multiple times a day
  • Underlying component infrastructure like Kubernetes, Linux Kernel, Istio, and Cilium sees regular upgrades and CVE patches on-demand or monthly.

Infrastructure

PaaS

  • DDoS protection is enabled for all Northflank managed clusters
  • Cilium is deployed by default providing network-policy restriction between namespaces (projects)
  • Istio is restricted to only share workload configuration with the proxies in the current namespace
  • When multi-project communication is enabled, connections are allowed one-way. They are limited by network-policies and Istio configuration resource sharing
  • The platform supports enabling Istio mutual-TLS which encrypts cluster-internal traffic between services
  • Kata Containers are used as the default runtime class for workloads in the cluster, to protect the nodes from vulnerability exploitation. This applies KVM and micro-VMs through Cloud Hypervisor to secure the workloads from the host kernel
    • Northflank may also use gVisor as an alternative to Kata Containers as the secure runtime for workloads when nested virtualization is unavailable
  • The Linux kernel running on both the host nodes and within Kata is regularly updated to the latest stable branch release
  • Secret injection is used to avoid storing secrets, environment variables, and sensitive configurations within Kubernetes
  • Volumes and volume backups are encrypted at rest by Google Cloud encryption keys
  • Logging and metrics credentials on workload clusters have write-only permissions to global storage
  • Components within the clusters are monitored for CVE notifications and are regularly patched in response to version releases or CVE notifications

BYOC

  • Available cloud provider authorization strategies:
    • API key based authorization
      • The user provides API keys to their cloud account which are encrypted and stored in our database. The secrets are long-lived.
      • Availability: This authorization strategy is available for all supported cloud providers.
    • Cross-Account / cross project authorization
      • The user grants access to a Northflank-controlled IAM principal in their cloud provider account. In the case of AWS, the IAM principal is an AWS role that resides in one of Northflank’s AWS accounts. The user grants permissions to that role by assigning a trust policy and a role policy to the role in their AWS account. In the case of GCP, the IAM principal is a service account that resides in one of Northflank’s GCP projects. The user grants permissions to that service account by granting permissions to its service account email in their GCP project.
      • With this approach, Northflank does not need to store long-lived tokens at all.
      • This strategy is available for AWS and GCP and is the recommended authorization strategy for cloud provider integrations.
  • PaaS security features (such as Kata Containers) can additionally be enabled on BYOC clusters.
  • Logging by default uses the Northflank PaaS, scoped to different tenants
    • Logging may be deployed self-hosted, and storage can be configured to stay within the user’s cloud account
  • Image storage by default uses the Northflank PaaS, with project scoped image access control
    • Image storage may also be configured to use a separately managed registry within the user’s cloud account
  • BYOC builds by default are run on the user’s cluster
    • A separate build-dedicated cluster can be selected which separates builds from running workloads
    • Builds can also be configured to run on Northflank’s build infrastructure

CI

  • For CI from version control, a more fine grained access token is generated which validates Git clone requests for a specific repository via a Northflank proxy service. This prevents CI from having access to more broadly scoped version control tokens and ensures access is only ever granted to relevant repositories for the duration of the build.

White Labelling

  • Northflank supports white labelling public DNS entries, such as for load balancers or generated default workload port DNS entries.
  • For version control integrations user controlled GitHub/Bitbucket/Gitlab applications can be provided to replace the Northflank default applications.

Internal Security

  • Google accounts are used for sign-in where possible, as well as 2FA
  • Accounts are assigned least-permissions
  • Where Google accounts are not used, 2FA is enforced and access is limited to only users who require access

Questions?

Please email us at security@northflank.com if you have any questions.