How Platform9 Enables Operational Security

Introduction

Platform9 delivers a SaaS managed open source based cloud service that enables enterprises to transform their existing data center infrastructure into an agile, self-service private cloud. In addition to being easy and efficient, Platform9 places major emphasis on ensuring operational security when delivering open source cloud frameworks like OpenStack and Kubernetes in a SaaS managed fashion. Platform9’s solutions are designed to keep enterprise infrastructure and workloads secure. The information below details the security measures we’ve designed within our infrastructure and product, as well as options available to administrators, that allows Platform9 to function as a secure platform to manage your infrastructure.

Platform9 Product Security

Below is a diagram which describes high-level Platform9 architecture, highlighting various components.

Single sign on (SAML) Support: Platform9 supports integration with SAML identity providers, helping enterprises have a single login policy (like MFA token, password length) across all applications. It also alleviates the need for adding/updating/removing individual users on Platform9 portal.
MFA (TOTP) support: Even though SAML integration with a dedicated identity provider is recommended, Platform9 supports use of TOTP (time-based one-time password) if a customer decides not to use SAML integration.
SSL with client-side authentication: Mutual authentication for communication with agent software. Each deployment unit has its own unique, self-signed root certificate authority. This certificate authority is used to generate 2048-bit keys that are in turn used to secure all communications between the deployment unit and agent software that interacts with it using SSL encryption. Both the deployment unit, and any agent software (including host agent and OpenStack/Kubernetes agent software) use these keys to mutually authenticate via https. This prevents any agent software configured for a different customer from mistakenly or maliciously accessing the deployment unit.
SSL for API and UI client: GeoTrust signed certificates for API clients. The services hosted by the deployment unit are accessed using REST APIs by the Clarity user interface or customer developed automation. These clients can authenticate the server by using GeoTrust signed certificates. The server authenticates the client with Keystone, the role-based identity service used by OpenStack or Kubernetes built in RBAC capabilities.
Code signing: Platform9 host-side software upgrades and installs additional component on premises on upgrade schedule and host re-configuration actions by users. These software packages are ‘signed’ by Platform9.
Restricted access user: Platform9 on-premises component run as user “pf9” group“pf9group.” The set of sudo privileges required by user pf9 can be obtained from Platform9 on request and can be used to further restrict access to the actions Platform9 can perform.
Metadata only: Platform9 deployment units only receive metadata from agent software, such as host hardware configuration, software packages information, relevant log files from the host, and virtual machine identifier and configuration. Deployment units do not receive data from running or offline virtual machines, or any other data from hosts.
No need to open ports: The deployment unit or any software therein doesn’t initiate a network session into any customer hosts. Authorized agents that are installed on hosts initiate necessary calls to the deployment unit using outbound, https connections. No new ports to open limits the attack surface area.
Roles and privileges: Administrators can limit access and, therefore, the security surface of the system by using pre-configured roles that have reduced privileges. For instance, most users of the system would be configured with the ‘self-service user’ role, which doesn’t allow them to perform protected operations on virtual machine instances that they do not own.

Platform9 Operational Security

Isolated customers: No shared multi-tenancy across customers. No two customers of Platform9 share a deployment unit.
Virtual firewall: Customers can restrict access to the deployment unit by specifying the IP settings of one or more allowable source networks.
Monthly updates: Deployment units are patched for security updates regularly. Updates are pushed monthly to include the latest security patches. Critical vulnerabilities are addressed and patched immediately.
Encryption at rest: Platform9 performs regular backups and all backups are encrypted.
Physical security: Platform9’s server equipment is secured in a level 3 datacenter and keys are only provided to authorized employees. Employees develop their software using computers with strong passwords and encrypted disk storage in case of loss or theft.
Data centers: Platform9 uses a well-known public cloud computing service provider to host customer production environments. These environments are configured for multi- geographical availability in case of a disaster or other outage in any specific geography.
Incident response: If despite all other protection in place, customer data is accessed without authorization, Platform9 will notify you. If personal information about customers is breached from Platform9, we will notify customers in accordance with California Law (California Civil Code Section 1798.29 and Section 1798.82).

Privacy

Guiding user’s privacy and that of their business data is something we take seriously, and we work hard to protect user information from unauthorized access. Our privacy policy is available along with our terms and conditions.

Summary

Platform9 helps enterprises manage their infrastructure as an agile, self-service, secure private cloud. To learn more about Platform9 and how it could add value to your business, please reach out to us at customer-success@platform9.com.

If Platform9 gets hacked, what controls are in place to limit damage?

There are multiple levels of security Platform9 employs. These measures limit the damage. Here are some of the important controls Platform9 has put in place.

Each customer account is separately maintained. Customer account access keys like SSH keys are different for each customer.
Platform9 uses Code Signing and all the component installed on customer premises are signed by Platform9 keys. So a malicious code cannot be installed through Platform9.
These code-signing keys are kept separate from the customer account. So in case one of the customer account is hacked no new malicious component can be installed by the hacker.
Platform9 on-premises components runs as user ‘pf9’ who has limited and published set of sudo privileges.

In the event that Platform9 finds evidence of a compromised cloud controller, the cloud controller instance is terminated.

What access controls are in place for employees of Platform9 when accessing customer account?

Only a limited set of ‘users’ have access to customer accounts. These include limited members of our devops team and senior engineering management only.
Customer support engineers are given access to a customer account on a ‘lease’ basis when needed. Further changes are being worked on ALL access are going to be leased based.
Access to customer accounts are audited.
Physical access to the servers holding the various secret is through a secured facility which is monitored 24×7 and only a handful of people on the team have access to it.

What is the metadata that you collect from my systems?

Platform9 primarily collects metadata about:

For Linux/KVM: Host servers operating system, memory, cpu, storage, network, virtual machine attributes such as usage and capacity.
For vSphere environments: Datastores, clusters, hosts, virtual machine attributes such as usage and capacity.

What access level do Platform9 services have? Does hostagent run as root? What control do I have over this?

Platform9 on-premises component runs as ‘pf9’ user (not root). User pf9 has a limited set of ‘sudo’ privileges.
For installation of components sudo is used.
Platform9 signs all its packages and Platform9 agents only install signed packages.

Can you access my resources without my permission? What controls are in place to prevent this?

For Linux-KVM: Platform9 components can only access the resources which they are installed on. This is further controlled by access to ‘pf9’ user as addressed above.
For vSphere: Platform9 components can only access the resources the vSphere user given to Platform9 is allowed to access. Platform9 support portal had details about the individual privileges needed.

What happens in case my DU (Deployment Unit which hosts a customer account) goes down? Or if I lose connectivity to it?

Platform9 monitors individual customer accounts for individual services and system connectivity as a whole. A single failure is not noticeable, but in case multiple cascaded failure occur Platform9 can recover from their failure pretty soon (we maintain 99.7% uptime and improving) and is backed by our SLA contract.
Once the connectivity is lost:
- An email notification is sent to the customer contact and remediation steps are taken.
- Virtual machines, storage and network component work as is without interruption.
- Any operation in progress are queued till the connection comes back.

What control do I have over the packages installed on my system? Over the repos being accessed?

Platform9 code signs each package that it installs, Platform9 components will also verify the signed packages before installation.
Platform9 relies on customer to setup their own 3rd party and public repos for Linux/KVM environment. For vSphere Platform9 encourages customers to configure their own repo but can also work with Platform9 supplied trusted repos.

What ports does Platform9 have access to? What are the vulnerabilities?

Platform9 doesn’t relies on on-premises component to access Platform9 cloud and as such doesn’t need any port in the firewall to be opened up.
Platform9 can provide result of penetration test on request (we perform penetration testing for each of our customer separately hence can’t share it publicly).

Is the Platform9 OpenStack controller shared?

No, each customer account runs in separate set of virtual machines.

Does Platform9 call into the customer’s environment?

Platform9 customer premises components call back into Platform9’s customer accounts, so technically no. This arrangement helps Platform9 components to talk through routers, NAT and HTTP proxy. Once the connection is established Platform9 and the on-premises components communicate bi-directionally.

General sign-in authentication questions: what other applications do we work with? Support for SAML, Okta, Duo, etc.?

Platform9 supports Okta SAML connector.
You can also configure SAML SSO with ADFS or OneLogin.
Further SAML integration can be enabled through a professional service arrangement.

How do you protect against DoS attacks?

The Platform9 cloud controller is hosted within an AWS VPC. Amazon provides basic DDoS protection on their EC2 infrastructure. See this white paper for details on how AWS monitors for DDoS attacks and secures their infrastructure.

We use restrictive security groups to only allow access to the controller from Platform9 infrastructure. We also monitor API access rates and errors; abnormal API access rates will alert our operations staff.