Overview
Humanitec is used across a wide range of companies of different sizes operating in different industries. Different companies have different requirements for security and compliance. This page outlines the ways in which Humanitec can be configured to meet those requirements.
Connectivity
To deploy Workloads and provision infrastructure, Humanitec requires network connectivity to various systems. This includes the Kubernetes API of clusters being deployed into and some instances of resources such as database instances. Since these systems generally reside in private networks, network connectivity from the Humanitec SaaS system and the systems needs to be established.
Humanitec provides 2 primary ways of configuring access, direct and an agent. There is a third option of using a bastion host specifically for working with Relation Database instances.
Direct
Control plane endpoints can be directly exposed to the public internet with an allow list including Humanitec’s source IPs.
The following are the current source IPs for Humanitec:
34.159.97.5735.198.74.9634.141.77.16234.89.188.21434.159.140.3534.89.165.141
These are not the public IPs your workloads will be using for egress. They depend on the cluster you are deploying to.
For the Humanitec default (demo) clusters, IPs may also be different.
Hint: To see the public IP of any deployed workload, have it log the output of this statement:
wget -qO- https://ipecho.net/plain | xargs echo
Agent
The Humanitec Agent is a small containerized Workload that runs within the client’s private network. The Agent establishes a secure encrypted tunnel with the Humanitec SaaS system. Using the Agent allows fine-grained control over which endpoints Humanitec can access. This also means that the private network does not have to be exposed to the public network.
At least one instance of the Agent should be run in each disconnected network.
Secret management
Secret management is an important part of any secure internal developer platform (IDP). Secrets can be generated as part of infrastructure provisioning; for example, database credentials or be supplied by developers; for example, API tokens for third-party services.
Humanitec has 2 modes of operation for secret management. Humanitec can act as the secret store, or it can work with external secret stores running in the client’s private network.
Humanitec as secret store
By default, Humanitec acts as the IDP’s secret manager. This is useful for organizations that seek a more fully managed experience.
All secrets directly via the API or indirectly via the CLI, UI or Terraform provider are securely stored in an internal secret vault. The Humanitec API doesn’t return submitted secrets. Secrets are only fetched from the secret store at deployment time and are used in the provisioning of resources or creating of Kubernetes Secret objects.
External secret stores
Humanitec can also be configured to use external secret stores. This is the preferred mode for organizations who want to ensure that secrets are always stored within their own networks.
In this mode, Humanitec does not store any secrets except for access credentials it requires to directly access systems. All workload and resource secrets are stored in the configured secret store.
To use this mode, it is necessary to run the Humanitec Operator in the Kubernetes cluster being deployed to. The operator has privilege access to extract secrets from the secret store and uses them as part of resource provisioning or injecting them into workloads as Kubernetes Secret object.
At this time, the following external secret stores are supported: