Supported Target Platforms

How Pulumi takes applications into the cloud is explained in sufficient detail in this article, but what clouds can you manage with Pulumi? Clearly the big hyperscalers will be part of the package: Pulumi not only supports AWS, Azure, and Google Cloud Platform but offers a massive feature set. AWS, for example, is just a roof under which hundreds of services now reside. Pulumi cannot address them all, but in a normal working day with AWS, admins are unlikely to worry about missing functionality. The same applies to Microsoft's Azure and Google's Cloud.

Private solutions are far much less well supported. Pulumi has a resource provider (the name of the plugins that extend Pulumi with support for certain OpenStack features) for OpenStack. However, the provider is far removed from supporting all the features that modern OpenStack installations offer and is limited to rather basic support. Pulumi cannot handle the more complex tasks, perhaps because most users simply use Pulumi with the large providers and do not want to deal with additional problems that arise when using Pulumi with private clouds. For example, if you are using a private cloud that cannot be accessed over the Internet, you will inevitably need the Pulumi Enterprise version, so you can operate the Pulumi service locally. If you want to access the large public clouds, you will have no problems with the program; however, it is not suitable for private clouds.

Support for Kubernetes

In addition to genuine infrastructure-as-a-service offerings, Pulumi now also offers strong support for Kubernetes. Little wonder: Strictly speaking, Kubernetes is nothing more than a fleet orchestrator. However, the magic takes place one level higher than in the classic clouds. Kubernetes assumes that it has access to executable systems on which it can install its components and operate containers. A tool like Pulumi would be difficult to imagine without support for Kubernetes; therefore, the developers integrated precisely this function into their software. However, the Pulumi service must be able to communicate with the Kubernetes API for the deployment to work. If the Kubernetes instance can only be reached over a local connection, a local Pulumi service is again needed, which requires the Enterprise version of the product.

Policy as Code

The Pulumi developers draw particular attention to one feature in terms of security, and the product has a kind of unique selling point: Policy as code is the main focus of the Pulumi CrossGuard product.

The narrative goes something like this: Individual developers should not have to ask for resources or manual approval from the manager for every Kubernetes cluster they want to start, because that would lead to enormous administrative overhead. However, administrators should not be able to do what they want on all cloud accounts of a company. An Amazon AWS instance in the appropriate configuration tends to burden your wallet to the extent of $1,000 or more per month. If an administrator's Pulumi project runs amok and starts virtual machines without anyone noticing, a rude awakening threatens at the end of the month in the form of a massive bill.

Pulumi therefore has the option to map a set of rules that provides different permissions for different developers – with the Enterprise version, only, for which you again need to put your money on the table; however, it opens a multitude of possibilities. Admins then have the option to define Policy Packs (Figure 5), which contain a set of rules or several related sets of rules that assign different authorizations to different users.

Figure 5: You can create Policy rules for Pulumi in Python notation with the Pulumi Enterprise version only, which is available for a charge.

In Policy Packs, granular permissions can be set at the API level of each cloud vendor down to the individual API call, including the parameters for each. For example, if an administrator is only to be allowed to start instances of a specific flavor on AWS, the Policy Pack provides a switch for this. Policy Packs also provide on-demand restrictions for where admins can start specific workloads. For example, if you want to run an unimportant workload on AWS, but only on cheap instances, it would be better to rule out Amazon's high-end data center in Frankfurt for the workload.

In addition to hard prohibitions, Policy Packs also provide warnings. If an admin uses certain services in a public cloud, Pulumi can display a note for the individual case that warns of financial or technical risks. Practically, the policies also use well-known programming languages, so they are implemented like all other programs in Pulumi. The downside is that you have to choose the corresponding descriptions and keywords for the individual scripting languages from the documentation and practice with them before you can create and use Policy Packs in a meaningful way.