What Humanitec does to uphold the highest security standards

When building an Internal Developer Platform (IDP) there are numerous factors to consider, but one core component stands out: The Platform Orchestrator. This pivotal piece orchestrates the collaboration between multiple tools, and serves as the core of your IDP. As you venture into selecting commercial or open-source tools to build your platform, it’s also imperative to prioritize security, and understand how you’ll protect your infrastructure and your data. In this article we’ll dive into how the Humanitec Platform Orchestrator not only upholds the highest security standards, but also empowers your organization to drive efficiency and productivity. By exploring the Platform Orchestrator’s security measures you can make a more informed choice that not only bolsters your IDP's security, but also supercharges your development workflow. In this article, we’ll cover the following:

• What Humanitec does internally to stay secure and compliant when using our SaaS offering
• The various modes available for customers to manage how Humanitec SaaS connects to their network
• The various modes available for customers to manage how their secrets are handled by Humanitec.

Humanitec components discussed in this article

• Humanitec Platform Orchestrator: This is Humanitec’s main product. It can be accessed via API, UI or CLI. The user interacts with it to deploy Workloads, Resource Definitions, configure Drivers, etc. In most configurations it requires read and/or write access to the clusters it manages, but it can be configured with GitOps which means access to the cluster would not be needed.  As we will see in this article, it requires at least read access to the clusters it manages, unless Humanitec deploys blindly via a GitOps process (which is technically possible).
• Humanitec Drivers: These are the code that runs in order to actually provision a Resource, and are an extension point for the Humanitec Platform Orchestrator.
• Humanitec Agent: This prevents the need to open up the internal network to the public internet by creating a secure tunnel between the SaaS Humanitec Platform Orchestrator.
• Humanitec Operator: Used to resolve secrets during deployment from inside the customer’s network, it also deploys manifests in the destination cluster, the Humanitec Operator is not required with all configurations. We’ll elaborate later on where it can be used.
• GitOps Operator: This is not a Humanitec component, but can be something like Flux or ArgoCD that’s used if the GitOps mode of operation is desired. Another benefit this provides is that when using Humanitec’s SaaS offering, the Platform Orchestrator doesn’t need any access to the clusters it manages.

We’ll dig deeper into these components later in this article.

What Humanitec does to stay secure and compliant

Humanitec does a number of things to stay secure and compliant, including:

• Regular pen tests to ensure our infrastructure is secure. Reports can be provided as needed, please contact security@humanitec.com
• Becoming ISO 27001:2013 certified as of March 31, 2023. Full certificate and reports are available as needed
• Running on GCP, hosted in Frankfurt am Main, Germany. All data stays in the EU under strict EU regulations that protect your information.
• Humanitec is GDPR compliant.
• Supporting  SAML (1.1 and 2.0 compliant) for single sign-on. In addition, you can also use your Google and GitHub ID to log in.

How Humanitec connects to network and clusters

The Platform Orchestrator runs in our infrastructure and requires access to your clusters to deploy Workloads and provision infrastructure. All connection types discussed here are encrypted so that all the data in transit is secured.

In this section we’ll next cover various connection patterns between Humanitec’s Platform Orchestrator and your Kubernetes (K8s) cluster, including:

1. Direct Connection (With Ip Whitelisting)
2. Bastion Host (For DBs only)
3. Agent

It’s important to note that Humanitec supports AKS (Azure), EKS (AWS), GKE (GCP) or any other K8s distribution out of the box.

1. Direct connection 

You can directly connect Humanitec to your cluster. In this case, the Platform Orchestrator requires ingress access to your K8s API. Humanitec offers a list of IPs you can whitelist so your API is not open to the entire world.

2. Bastion Host

The Bastion host can be used by some of the built-in database Drivers to connect to databases in the customer's internal infrastructure. A Bastion host sitting in a DMZ of the user can forward the request internally. This bastion host can also whitelist the Humanitec IPs, so it’s not open to the world.

3. Agent

Humanitec’s agent runs anywhere inside the customer network with access to the cluster, and is used to create a secure tunnel from inside the customer network to the Platform Orchestrator.

In this case, the agent needs egress stateful access to create the tunnel with the Platform Orchestrator, which will use that tunnel to forward the request to the private network. The agent cannot see the data as it’s all encrypted; it just forwards the requests.

What about self-hosted options?

Humanitec offers a self-hosted option for all its products. In this mode, you don’t need to worry about the above, as the entire connectivity goes via your internal network.

What data flows in and out of Humanitec? 

It’s worth mentioning that only required data flows in and out of Humanitec. Your source code, DB data, and any other data that the Resources you provision hold and handle do NOT flow to and from Humanitec, as shown in the following diagram:

Humanitec only holds the following data from the customer:

• Infrastructure specifications: Such as Resource Driver configuration
• Workload specifications: Detailing the configuration of the Workload
• Workload logs: This is optional, and it can be disabled or sent somewhere else.

The only PII that Humanitec holds is the email address and name of the user. 

Managing secrets with Humanitec

When deploying Workloads or handling infrastructure, secret sprawl can be an issue. In addition, knowing where your secrets are stored is important because a compromised secret store will put your entire organization at risk. Let's take a look at where and how secrets are used with Humanitec, and the options available to store them.

Secrets are used in Humanitec for the following use cases:

• Store Resource secrets
• Configure and create Resources in your cloud provider.
• Secret application values for Workloads (For example API tokens)
• Configuring the Workloads using Placeholders.

Users generally add secrets via the Platform Orchestrator for values that are not for Resources (using Shared Values). For all other values, Humanitec will use outputs from Resources to configure the Workloads. You can also use secrets to configure Resource Drivers.

There are four ways in which you can manage your secrets in Humanitec, which are numbered below in order of complexity (least to most):

1. Full Saas: Secrets fully managed by Humanitec

When doing full SaaS, customer secrets are stored internally in Humanitec infrastructure. We secure these secrets in our Internal Hashicorp Vault. In this mode, the Platform Orchestrator has read and write access to the secret store.

2. Secrets stored by the customer but can be used outside the customer’s network

The Platform Orchestrator sits inside the Humanitec infrastructure and has write access to the secret store inside the customer infrastructure to add secret values, the customer can choose to turn read access off to the Platform Orchestrator. The Drivers inside the Humanitec infrastructure get secrets from the operator running inside the customer’s cluster (more on the operator later), which has read-and-write access to the secret store. 

3. Secrets stored by the customer that do not leave the customer’s network

Same as above, except that the Drivers are hosted by the client and the operator can pass secrets to them completely via the customer’s internal network.

4. Self-hosted: No data leaves the customer network

Everything is hosted by the client; all access is internal. Operator usage is optional.

Using the operator

When a customer decides to manage secrets internally, Humanitec uses a Kubernetes operator. The Platform Orchestrator can use this to help with deployments involving secrets that are only accessible on private networks and must not be stored elsewhere.

Let’s first go back to how it works without the operator: When using full SaaS, the Platform Orchestrator securely stores any secrets an application needs in a separate, internal secret store. This includes the secrets used in Resource provisioning, such as database credentials, and the secrets set up by developers as shared app values and secrets. The Platform Orchestrator inserts rendered K8s manifests into the target cluster when an application is deployed. Any necessary K8s Secret manifests are also included here. The Platform Orchestrator retrieves the secrets from its internal Secret storage to produce these Secret manifests.

This is how it works with the operator: When configuring the Platform Orchestrator to use secret stores inside the client infrastructure as described above, read access to secrets will no longer be available to the Platform Orchestrator. The manifests deployed into the K8s cluster cannot, therefore, be rendered entirely by Humanitec.

The Platform Orchestrator renders the manifests only partially when configured with an external secret store and generates a set of instructions outlining how to complete the rendering procedure. The target K8s cluster receives this information as a set of CRDs. The Humanitec Operator picks up these CRDs and completes the remaining rendering stages. This entails contacting any Drivers required to provision Resources and obtaining secrets from the secret store.

To recap, the Humanitec Operator performs the following functions:

• Reads CRDs when they are created/updated
• Create K8s manifests
• Calls Drivers if required to provision Resources.

• If the Driver takes secrets as inputs, these are stored in the secret store.
• Driver cookies are also stored in the secret store.

• Resolve Placeholders in the configuration
• Populates status information for Humanitec to read

The Humanitec Operator is always required when using SaaS, and the customer wants to store secrets internally. It is not used for full SaaS, and it is only optional for on-prem.

To sum up, here is the full spectrum of security:

GitOps mode of operation

Even when using the Humanitec Operator, the Platform Orchestrator still needs permission to write the CRDs in the destination cluster. But with GitOps, the Platform Orchestrator doesn’t strictly need access to the cluster. 

In this case, Humanitec can be used with a GitOps operator like ArgoCD or Flux. In this scenario, The Platform Orchestrator writes the manifest files to a repository, and then the GitOps operator reconciles that in the cluster.

This pattern can benefit those who want to minimize the access of the Platform Orchestrator to their clusters when using SaaS, because it means that the Platform Orchestrator doesn’t strictly need access to the cluster.

The GitOps mode of operation for using SaaS with a customer managing secrets internally looks like this (in this graph, the Drivers are in Humanitec infrastructure):

Humanitec covers all levels of enterprise security

In this article, we have seen that SaaS Humanitec has three different connection modes to the client’s infrastructure:

1. Direct connection: The connection to the K8s API and Humanitec happens over the internet, and it is fully encrypted. IP whitelisting can mitigate some security concerns here about global access.
2. Bastion host (For DBs only): This connects securely to the customer’s internal DBs.
3. Agent-based: This agent creates a tunnel from inside the customer’s network to forward requests from Humanitec to the user’s K8s Clusters. 
4. Self-hosted (Not SaaS): All connection happens internally.

Following this we’ve highlighted the various options available for clients to secure their secrets:

1. Full Saas: The secrets are stored in our infrastructure.
2. Customer stored secrets with Drivers hosted at Humanitec 
3. Customer stored secrets with Drivers hosted at the client’s servers
4. Self-hosted: Everything is hosted by the client.

We’ve explained how our operator helps keep secrets secure within the company’s infrastructure, including how GitOps can be used to further eliminate access from the Platform Orchestrator to the clusters.

Finally, we discussed the various ways that Humanitec can bolster infrastructure security when using our SaaS offering, such as being ISO certified.

In summary, Humanitec offers security modes for all levels of enterprise security. Our Platform Orchestrator enables security best practices by design, and ultimately it is down to the customer to pick which one works best for them.