LEAP Platform for Service Providers
Its goal is to make it as painless as possible for sysadmins to deploy and maintain a service provider’s infrastructure for secure communication.
REQUIREMENTS – Before you begin, make sure you meet these requirements:
- Debian Servers: Servers that you deploy to must be running Debian Jessie, and no other distribution or version.
- Real or Paravirtualized Servers: Servers must be real machines or paravirtualized VMs (e.g. KVM, Xen, OpenStack, AWS, Google Compute). OS level virtualization is not supported (e.g. OpenVZ, Linux-VServer, etc), nor are system emulators (VirtualBox, QEMU, etc).
- Your Workstation: You must have a Linux or Mac computer to deploy from (this can be a headless machine with no GUI). Windows is not supported (Cygwin would probably work, but is untested).
- Your Own Domain: You must own a domain name. Before your provider can be put into production, you will need to make modifications to the DNS for the provider’s domain.
The LEAP Platform consists of three parts, detailed below:
The LEAP platform recipes define an abstract service provider. It is a set of Puppet modules designed to work together to provide to sysadmins everything they need to manage a service provider infrastructure that provides secure communication services.
LEAP maintains a repository of platform recipes, which typically do not need to be modified, although it can be forked and merged as desired. Most service providers using the LEAP platform can use the same set of platform recipes.
As these recipes consist in abstract definitions, in order to configure settings for a particular service provider a system administrator has to create a provider instance (see below).
LEAP’s platform recipes are distributed as a git repository:
A provider instance is a directory tree (typically tracked in git) containing all the configurations for a service provider’s infrastructure. A provider instance lives on your workstation, not on the server.
A provider instance primarily consists of:
- A pointer to the platform recipes.
- A global configuration file for the provider.
- A configuration file for each server (node) in the provider’s infrastructure.
- Additional files, such as certificates and keys.
A minimal provider instance directory looks like this:
└── bitmask # provider instance directory. ├── Leapfile # settings for the `leap` command line tool. ├── provider.json # global settings of the provider. ├── common.json # settings common to all nodes. ├── nodes/ # a directory for node configurations. ├── files/ # keys, certificates, and other files. └── users/ # public key information for privileged sysadmins.
A provider instance directory contains everything needed to manage all the servers that compose a provider’s infrastructure. Because of this, any versioning tool and development work-flow can be used to manage your provider instance.
leap command line tool is used by sysadmins to manage everything about a service provider’s infrastructure.
Keep these rules in mind:
leapis run on your workstation: The
leapcommand is always run locally on your workstation, never on a server you are deploying to.
leapis run from within a provider instance: The
leapcommand requires that the current working directory is a valid provider instance, except when running
leap newto create a new provider instance.
leap command line has many capabilities, including:
- Create, initialize, and deploy nodes.
- Manage keys and certificates.
- Query information about the node configurations.
Everything about your provider is managed by editing JSON configuration files and running
We recommend reading the platform documentation in the following order: