Snapshot 244555
Normalized text
Scripts and page chrome removed; this is what change detection compares.
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 SOC 2: Yes HIPAA: Yes ISO 27001: Yes ISO 27018: No SOC 2 Type II HIPAA ISO 27001 Northflank has achieved SOC 2 Type 2 compliance, demonstrating that the platform meets rigorous independent standards for security, availability, and confidentiality. The SOC 2 audit evaluates the design and operational effectiveness of our controls over an extended period, providing assurance that our security practices are consistently applied. Northflank is HIPAA compliant, meeting the standards required to handle protected health information (PHI). Under an Enterprise contract, we support Business Associate Agreements (BAAs) and provide the technical and organisational safeguards needed to run healthcare workloads securely on the platform. Northflank is ISO 27001 certified, demonstrating that our information security management system meets the internationally recognised standard for protecting the confidentiality, integrity, and availability of customer data. Request access to our trust center here: trust.northflank.com. Security is built into Northflank from the ground up. We maintain continuous monitoring of our controls and processes, supported by automated compliance tooling and regular internal reviews. We plan to begin penetration tests on a recurring basis 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.