This is one in a series of posts about the Akamai 2018 Spring Release. For an overview of the Spring Release, see our post here.
Last fall we announced a ton of capabilities to enable Akamai users to seamlessly integrate CDN operations into their existing CI/CD pipelines. This was only the first step, and we’re doubling down on enabling such capabilities focused on self-serviceability, ease of use, and speed. As part of our 2018 Spring Release, we’re excited to announce even more Akamai for DevOps initiatives.
More automation is a key driver for our 2018 Spring Release announcements. We know you want to treat CDN-related changes just like any other piece of code. This basically translates to having CDN rule changes integrated into the primary code deployment pipeline versus a separate stream. A key capability we’re introducing this fall is Promotional Deployment – a CLI package that enables users to automate the promotion of changes between different environments in their deployment pipeline.
How does this work? A typical automated pipeline consists of lower environments (dev, QA, integration, etc) that code flows through. As part of the continuous integration cycle, a change is made in the lowest environment (assume dev), tested out completely there, and then promoted to the next environment (assume QA), and so on.
The entire testing and promotion process is automated once the code is first checked in via a Jenkins, CircleCI, or any other build automation tool. Promotional Deployment enables you to integrate CDN changes into this deployment pipeline by parametrizing a configuration file to cater to different environments, and then allowing the promotion of changes between these different environments.
create-pipeline command lets you define different environments and map them to your config. Typically this is a one-time setup, but can be repeated as often as required. A
promote command will then enable users to promote configuration changes within the pipeline as often as required.
As with any other CLI command, you can simply integrate this into your build automation tools, for example, to promote after a series of tests are run and successful. Promotional Deployment goes beta for our 2018 Spring Release. If you’re interested, sign up here.
Check out a demo of Promotional Deployment in the video here.
DevOps for Security
As mentioned last Fall, our goal is to build these capabilities without compromising on any reliability or security standards, however, we want to take this one step further, and as part of the Spring Release, we’re introducing a series of DevOps capabilities to make working with our security products easier.
First, we are extending our API and CLI capabilities to our security products. Many Akamai customers require the ability to automate security configurations so that they can keep up with evolving threats, the growth of their organization, and their information security needs. To that end, we’ve enabled programmatic changes to Kona Site Defender configurations, which enables the following use cases:
- Protect a new property by adding a new hostname or path to an existing security configuration and policy.
- Export your security configuration as JSON to manage in your tooling and understand what protection measures are in place.
- Create/edit/delete a custom rule used as a virtual patch.
- Activate a security configuration.
Let’s take a look at the use cases cited above more closely.
Protect New Properties
You can now programmatically add multiple new hostnames into a security configuration. This enables you to add a property that has already been defined on your Akamai CDN configuration into a Cloud Security configuration for protection. As a result, you can secure the property with an existing firewall and/or bot protection policy without considerable effort.
Export Security Configurations
It’s difficult to incorporate configuration and review tasks from diverse groups into an existing scheduled release process in a seamless way. To make this process more efficient, you can manage infrastructure as code. This means that your configurations are loaded into repositories for change control tracking and approvals, with common tasks managed via automation tools. This feature allows the client to export an Akamai Security Configuration as JSON format, greatly improving manageability.
Create Custom Rules
Akamai custom rules provide a lot of flexibility to fulfill different security requirements you might have for your Web Application Firewall configurations. This use case allows the capacity to enable or disable custom rules and handle their respective actions in a security configuration. This enhances the manageability of custom rules when they are used for things like virtual patching, or any requirement which might involve frequently rolling out new custom rules to production.
Activate Security Configurations
Finally, you can programmatically activate security configurations on staging or production, simplifying the process of coordinating activation dates and times. This adds more agility to the change management processes in terms of having a structured procedure for activation or rollback of configuration changes, and gives you a much faster response time under duress.
As mentioned, all of these use cases will be covered via the Akamai CLI to provide more simplicity and automation. We are also adding CLI support for Fast DNS – find out more here.
Finally, all of our security use cases will incorporate faster activation times that are supported by our delivery products. This ensures more flexibility as users continuously iterate security policies and react quickly to any duress. Fast activation enables users to push configurations to staging and production in less than 3 and 10 minutes, respectively.