SHIELD Genesis Kit

This is a Genesis Kit for the SHIELD Data Protection System, from Stark & Wayne. When using genesis to deploy this kit, you will get a fully-functional SHIELD deployment for backing up + restoring your data services.

Quick Start

To use it, you don't even need to clone this repository! Just run the following (using Genesis v2):

# create a shield-deployments repo using the latest version of the SHIELD kit
genesis init --kit shield

# create a shield-deployments repo using v1.0.0 of the SHIELD kit
genesis init --kit shield/1.0.0

# create a my-shield-configs repo using the latest version of the SHIELD kit
genesis init --kit shield -d my-shield-configs

Once created, refer to the deployment repo's README for information on creating new environments + deploying them.

Subkits

Authentication Backends

When deploying your SHIELD, this kit provides three options for configuring how users authenticate to SHIELD. One of these three must be specified

• github-oauth - Sets up OAuth2 using github.com as the OAuth Provider. This allows you to give multiple people access to SHIELD, with access based on GitHub org membership.
• cf-oauth - Sets up OAuth2 using a user-supplied UAA as the OAuth Provider. This allows you to give multiple people access to SHIELD with access based on their group membership inside the UAA.
• http-auth - Sets up HTTP Basic Authentication and a single user/password to be used by SHIELD for authenticating.

Azure

When deploying SHIELD on azure, you may want to consider the azure subkit for reconfiguring the availability zones in play. Since Azure uses availability sets, rather than zones, there is typically only one zone in play for networks/VMs, and the availability set would be defined by the Azure CPI automatically, or via cloud_properties in your Cloud Config.

Params

Base Params

There are no required params for SHIELD, when deployed with no subkits enabled. However, the following params can be overridden to customize your installation if needed:

• params.installation - controls the name of the SHIELD installation, as reported from inside the SHIELD UI. This defaults to S.H.I.E.L.D. Alpha
• params.shield_disk_pool - used to define the persistent disk pool that the SHIELD VM will be given. This pool must exist in the Cloud Config of the BOSH director that deploys SHIELD. This defaults to shield.
• params.shield_vm_type - used to define the Cloud Config VM type that the SHIELD VM will be given. This VM type must exist in the Cloud config of the BOSH director that deploys SHIELD. This defaults to small, as the SHIELD daemon does not consume many resources.
• params.shield_network - used to define the Cloud Config network that the SHIELD VM will be located on. This network must exist in the Cloud Config of the BOSH director that deploys SHIELD. It defaults to shield, but typically this can be located on a shared-infrastructure network. SHIELD will need to be in a network that has SSH access to all of the VMs that have SHIELD agents that will be executing backup jobs.

cf-oauth Params

Required Params:

• UAA Client ID - In order to validate OAuth attempts, SHIELD needs to authenticate to the UAA. This is the client ID of the UAA client that SHIELD will use to communicate with the UAA. It will need the openid,scim.real scopes. This data will be stored in Vault.
• UAA Client Secret - This is the UAA client secret for the above client. This data stored in Vault.
• params.authz_allowed_groups - A list of UAA groups for authorizing SHIELD users. If a user authenticating to SHIELD is in at least one of the defined groups, they are allowed into shield.

github-oauth Params

Required params:

• GitHub OAuth Client ID - In order to validate OAuth attempts, SHIELD needs to authenticate to GitHub. When you configure an OAuth integration with GitHub, this will be the client_id. See https://developer.github.com/v3/oauth/ for more info.
• GitHub OAuth Client Secret - This is the GitHub client_secret for the above OAuth client. This data stored in Vault.
• params.authz_allowed_groups - A list of GitHub Organizations for authorizing SHIELD users. If a user authenticating to SHIELD is in at least one of the defined orgs, they are allowed into shield.

Cloud Config

By default, SHIELD uses the following VM types/networks/disk pools from your Cloud Config. Feel free to override them in your environment, if you would rather they use entities already existing in your Cloud Foundry:

params:
  shield_network:   shield
  shield_disk_pool: shield # should be at least 1GB
  shield_vm_type:   small # VMs should have at least 1 CPU, and 1GB of memory