Skip to content
Fugue now supports the Amazon Web Services (AWS) GovCloud region, which means federal agencies, like enterprises, can automate operations in the cloud fast, while simultaneously meeting regulatory demands. Fugue deployments start with powerful, but easy-to-understand code declarations in a composition that governs a system’s infrastructure. By including select libraries in that composition with simple import statements, a particular agency’s compliance regime gets integrated from the start. This kind of fully realized policy-as-code provides a scalable protocol for agency cloud ops and increases speed to mission.

 

The Power Behind Policy-as-Code

 

The power behind policy-as-code lies in validations. Fugue ships with some common validations, but also enables agencies and businesses to write their own. Validations are just user-definable functions that inspect a type in Fugue composition code and throw compiler errors if parameters aren’t met. No infrastructure is created until a correction is made. That saves time and money.

 

With validations, Fugue enforces whatever kinds of rules or business logic an application or agency requires. For example, since Auto Scaling is not permitted to contain ITAR-related data, a validation specific to Auto Scaling resources can be written to trigger errors if the rule is violated. Or, you may have a HIPAA rule that states certain EC2 instances must not run on shared tenancy hardware. Every government agency is concerned with NIST SP 800-53—its requirements can be coded into your language libraries up front for true DevSecOps integration. Perhaps you also have rules internal to your organization, one that says every VPC needs to allow SSH into it from a management host or that the network block for your VPC must be of a particular size. You’re covered. Validations, as code expressions in the context of a centralized cloud control system, can be customized to easily implement external policies and internal ops rules across very large applications. And, they can be easily replicated across dev, test, staging, and production environments.

 

How Validations Work

 

As noted, validations currently can be imported as a library into a composition with a single statement. In an upcoming release, they can be loaded directly onto the Conductor for additional security. Fugue’s built-in compiler (lwc) provides helpful error messages with specific, human-readable direction if a validation is violated. Consider the diagram below:

 

validations.png

 

Client-side validations in Fugue (shown on the left) essentially are a way of extending error-checking that the compiler already does. With Conductor-side validations (shown on the right), no one in an organization can skirt policy by not running validations locally or forgetting an import statement, etc., because the Conductor, as an isolated entity, will refuse to run anything that violates policy attached directly to it.

 

The big picture here is that validations simplify compliance and keep it tied to one source of infrastructure truth that is enforced continuously. Using validations means speed, certainty, and innovation are not sacrificed for mandatory compliance regimes. Policy and security compliance, in most organizations, remain a manual, expensive, and slow process to integrate well. The solution is in compiled policy-as-code that emphasizes validations.

 

In the Latest Public Release

 

In the public release of Fugue featured at the AWS Public Sector Summit, support of the GovCloud region and numerous product improvements have been made available. Just visit Fugue’s Download Portal to try it out or to upgrade. Here’s a quick run-down of specifics:

 

  • The Conductor is now supported to run compositions in AWS GovCloud. Note that a Conductor in GovCloud can run things only in GovCloud.

  • We've added some validations to the standard library that will throw an error if you're trying to use unsupported cloud services or features in GovCloud.

  • The Conductor now publishes its execution plans to SNS topics, filtered by the source of the job. These topics are prefixed with fugue-notifications-. That means that if customers want to get pushed notifications every time Fugue changes things, they can!

  • The fugue init command now will automatically look up the correct AMI ID if one is not provided.

  • Fugue credentials are now be stored in a separate file from fugue.yaml.

  • The Fugue CLI now supports credential profiles in a credential file, making it easier to work with multiple RBAC users.

  • The Fugue CLI now supports a search path for both fugue.yaml and the credentials file, making it easier to work with multiple directories of compositions.

  • fugue install now installs two IAM policies allowing you to use or manage Fugue. These will be updated by fugue upgrade for future releases.

  • The CLI now reports the currently installed Conductor AMI, as well as the fugue-client package version in the --version command.

  • The fugue-client package now includes lwserver, an LSP server for Ludwig that works with editor integrations, like our VS-Code mode for Ludwig.

  • RBAC policies can now refer to an account by its name, not just its ID.

  • The support tool is no longer a separate tool. It's now a fugue subcommand: fugue support.

  • Many other bug fixes and improvements!

 

Full release notes are available on the Download Portal. Give Fugue a spin! Contact us for a Team Conductor.

 

Categorized Under