Here at Stark & Wayne, we’ve been heads-down for the past several months, working on the next iteration of SHIELD, our data protection solution. We’ve got a lot of great stuff in store, and I wanted to take a moment to highlight some of the major features we will be launching with SHIELD v8.
(If you’re feeling particularly nostalgic, you may want to read the previous post in this series, SHIELD: A Look Back)
At-Rest Encryption
The SHIELD team has always taken data security seriously, and the system architecture leverages encryption for all data as it transits the network, but up until now, operators had to rely on the cloud storage layer itself to provide at-rest encryption.
No more.
Starting in SHIELD v8, backup archives will be encrypted immediately before they are stored in the cloud, using AES-256. Each archive gets a unique key and initialization vector, to protect against statistical fingerprinting attacks against similar or identical backup archives, and the secrets are stored in a dedicated vault of secrets, used and accessible only by the SHIELD Core.
Your sensitive data is now protected; even if someone has read access to (for example) your Amazon S3 bucket, they won’t be able to decipher the backup archives to get at the sensitive information.
Roles and Access Control
Prior versions of SHIELD featured authentication, but lacked fine-grained authorization. If you could login into SHIELD, you had full run of the system.
SHIELD v8 introduces six different roles that limit and restrict access to the various parts of SHIELD and its data set / configuration:
- Site Administrator – Full control.
root-level access. - Site Manager – Manages tenants (more on that in a bit) and who is assigned to each tenant.
- Site Engineer – Manages shared resources like global cloud storage definitions and retention policy templates.
- Tenant Administrator – Full control of a single tenant (we’ll get to tenants shortly).
- Tenant Engineer – Manages target, storage, retention policy, and job configuration for a tenant.
- Tenant Operator – Minimal access to perform restore operations, and run, pause, and unpause jobs.
Leveraging roles, SHIELD site operators will be able to open up their SHIELD installations to a wider operations / infrastructure team, safe in the knowledge that critical configuration and sensitive tasks will be limited to a trusted few.
Multi-Tenancy
The largest operational change in SHIELD v8, multi-tenancy allows a single SHIELD installation to be safely shared by two or more distinct teams, without anyone stepping on anyone else’s toes.
Inside of SHIELD, each tenant has its own set of retention policies, cloud storage configurations, data systems, and jobs. People can be granted one of three roles on a tenant (admin, engineer, or operator), affording them different levels of control over these resources.
If you want, you can put people in multiple tenants, and they can switch between the tenants they belong to.
(For those of you familiar with Github, we stole the idea of Organizations from them and adapted it to the needs of SHIELD.)
Not all things need to be shared, however, and SHIELD v8 allows SHIELD site engineers to define global storage systems and retention policy templates. Any tenant can use a global storage system in their job configuration, but won’t be able to see the configuration (so your Amazon S3 credentials are safe and sound). Retention Policy Templates are copied into each tenant when they are created, so everyone gets a good "starting point."
An Operator-Focused Web UI
The SHIELD Web User Interface gets a complete redesign in SHIELD v8, bringing with it a new, more operator-centric approach to common data protection tasks. The new UI features some handy workflows for common tasks like performing ad hoc backups, restoring from the last good archive, and configuring new jobs.
They say a picture is worth a thousand words, so here’s a before-and-after screenshot throwdown, with the new v8 UI on the right:
Third Party Authentication Providers
Of definite interest to enterprise Cloud Foundry / BOSH shops, SHIELD v8 will support pluggable authentication providers for authenticating against third part systems like Github (both github.com and Github Enterprise) and Cloud Foundry UAA. These providers are fully supported in both the web interface and the shield command-line utility.
SHIELD site administrators can configure these providers to automatically map logical groups inside of Github / UAA into SHIELD tenant / role assignments. For example, you can assign everyone in your company Github organization the Tenant Operator role in your company SHIELD Tenant. If you are using UAA to support BOSH teams, you can map those BOSH teams into SHIELD tenants and enforce the same separation for backups as you do for deployments.
SHIELD v8 also supports locally-managed accounts, if you still want the power and flexibility of tenants, but don’t have a suitable 3rd party system to authenticate against.
Oh, and token authentication is still a thing too, since automation is key to a healthy infrastructure.
Agent Metadata
SHIELD has always been a loosely connected network of agents working together to perform backup and recovery operations, but with SHIELD v8, that network becomes a little more tight-knit and more self-aware.
SHIELD v8 agents register with their SHIELD Core, providing it important metadata information like:
- What version of the SHIELD software is the agent running?
- What plugins are installed on the agent?
- What configuration parameters do those plugins accept?
This information allows the new web UI to provide a more operator-friendly method of configuring target systems and cloud storage, by way of forms and widgets instead of manually entered JSON (we’re really sorry about that UX faux pas).
SHIELD site operators can use the health and version information reported by registered agents to track down problems before they become outages, and to find misconfigurations, lagging versions, and other incompatibilities.
Cloud Storage Health and Usage
Prior to SHIELD v8, site operators were generally unaware that a cloud storage provider was unhealthy, or out of space, until a scheduled job failed, usually early in the morning.
We’re fixing that in SHIELD v8.
Now, the SHIELD Core will regularly run liveness checks against each configured cloud storage solution to verify that the remote system is reachable, that credentials haven’t been revoked, etc. This way, operators will be made aware of potential problems before the 3 a.m. backups start kicking off and failing.
Stronger Disaster Recovery
SHIELD v8 sports an internal database engine for its configuration and metadata, which enables a holistic method of backing up SHIELD itself, and properly restoring it to a working state in the event of a datacenter-level outage.
Docs, Docs, and More Docs
Last but not least, SHIELD v8 will be launching with a full-complement of reference documentation and task-based guides on everything from tenant management to authentication configuration. All of this lovely documentation will be collected in one place, a new project-specific website for SHIELD itself.
Stay Tuned
We’ve got a lot of exciting stuff coming with the SHIELD v8 launch, so stay tuned for future blog posts, and maybe even some demo videos, as we take deeper dives into the new functionality that makes SHIELD v8 such a compelling solution.
Spread the word
