Business & Technology
Many organizations have adopted Infrastructure as Code (IaC) methodologies and are now leveraging IaC tools to create and manage complex deployments that would otherwise take days or weeks to implement. With the REST APIs and integration with popular IaC tools such as Terraform, Fortinet has enabled organizations to automate the provisioning of security services to various virtualization and cloud platforms with CloudFormation.
Recently, Fortinet became an official Terraform provider, allowing users to directly create and manage Fortinet-specific resources, such as system interfaces and firewall policies. Additionally, Fortinet has taken advantage of cloud native IaC tools such as AWS CloudFormation service to build solutions, including CloudFormation templates, that allow automatic deployment of its products along with the required AWS resources. While those ready-made templates automate provisioning of the AWS resources, organizations often need to rely on AWS services and constructs such as User Data and AWS Lambda Function to create third-party specific resources.
Now, with the integration of its newly-launched AWS CloudFormation third-party resource provider framework, Fortinet has taken its IaC and AWS automation offerings to the next level.
Today, if customers want to automate the configuration of their third-party security services running in AWS accounts, they either rely on User Data and custom scripts to push the configuration during the bootstrapping process, also known as day 0. Or, they need to leverage services such as AWS Lambda Function to interact with third-party resources via an API at some later stage of the application lifecycle.
For example, in order to create a new firewall admin account, after the VM boots up, AWS users would have to run a custom script. However, the recent enhancement to the AWS CloudFormation service allows vendors to model and automate third-party resources, such as a FortiGate admin account, by enabling them as resource providers for the CloudFormation service.
Resource providers are treated as first-class citizens within CloudFormation. One can use CloudFormation capabilities to create, provision, and manage these resources in a safe and repeatable manner, just as you would any AWS resource. Using resource providers for third-party resources provides users a way to reliably manage these resources using a single tool, without having to resort to error-prone and time-consuming methods like manual configuration or custom scripts. An end user would only need to declare these resources in the same manner as they would declare native AWS resources such as EC2 instances.
A resource provider includes a resource type specification, as well as handlers that control API interactions with the underlying AWS or third-party services. There are three major steps in developing a resource provider:
Model – create and validate a schema that serves as the definition of a resource. The first step in creating a custom resource is modeling that resource, which involves generating a schema that defines the resource, its properties, and their attributes.
Develop – add logic that controls what happens to the resource at each stage in its lifecycle. Once a resource type is modeled its schema is validated, the next step is to develop the resource which consists of implementing “Create”, “Read”, “Update”, and “Delete” handlers.
Register – register the resource provider with CloudFormation in order to make it available for use in CloudFormation templates. Once registered, custom resource providers can be viewed in the CloudFormation registry section of the AWS CloudFormation console.
Additionally, runtime logging via AWS CloudWatch can be enabled. This enables the accessing of resource logs to help diagnose and debug any issues.
As automation has long been one of the main pillars of the Fortinet cloud security strategy, we have now integrated our offerings with the AWS CloudFormation third-party resource provider framework. The goal is to provide organizations with a seamless experience in automating the creation of Fortinet-specific resources such as system interfaces, and admin accounts.
CRUD handlers for each of these resources have also been implemented to ensure full support for every stage of the lifecycle of a resource. For example, “Create” stack applied to a CloudFormation template that includes a FortiGate (Fortinet Next Generation Firewall) DNS System as a declared resource, will invoke the create handler of that resource. Similarly, “Update” stack operation will result in the invocation of the update handler of the System DNS resource provider.
This new integration simplifies many use cases that have historically relied on manual and/or custom invocation of third-party resources. In the first release, creating three FortiGate resources within the CloudFormation will be supported. These resources are System Interface, System DNS, and Admin Account.
For example, customers can now take advantage of the Fortinet “Admin Account” resource provider to directly create admin accounts on a FortiGate. In the future we plan to support creating Tunnel interfaces on a FortiGate to provision VPN IPsec tunnels between FortiGate devices and AWS-managed services such as the AWS Transit Gateway. Without this resource provider, users would have to write error-prone User Data scripts or custom Lambda Functions triggered by certain events in their AWS accounts.
Fortinet’s CloudFormation resource provider support provides organizations with a seamless way to create, update, and delete firewall resources in AWS accounts. It abstracts away the underlying complexity, thereby allowing customers to deploy Fortinet firewall resources in the same way as they would deploy any native AWS resource.
Read about how Fortinet integrates with HashiCorp Terraform.
Learn more about how Fortinet’s multi-cloud solutions provide visibility and control across cloud infrastructures to secure applications and connectivity.