Over the last few months, I've been talking to many development and test teams who deliver their sites and applications through the Akamai platform. One common challenge they face is how to test their Akamai delivery configurations on the Internet against their private development and QA environments behind the firewall. Most operate on a DevOps model with the goal of performing end-to-end testing throughout the software development lifecycle in order to find bugs and interoperability issues (e.g., misconfigured headers) earlier in the development process.
As noted by Ron Patton in Software Testing, the cost of finding a bug increases rapidly as the development process progresses, so finding these issues early in the process saves a lot of time and money. The challenge these teams have faced historically has been how to allow the Akamai delivery configuration access to these development and QA environments. Because these environments are typically private and not exposed to the internet, the standard approach has been to move into the DMZ.
Challenges presented by the DMZ
Unfortunately, exposing these environments on the Internet via the DMZ creates both security and complexity concerns. From a security standpoint, how do you ensure that only authenticated and authorized users get access to these servers? A common and less-secure option is to whitelist IPs in the firewall as well as in the Akamai delivery configuration, but this greatly adds to the complexity—especially when you have remote developers and testers whose IPs can change. Adding to that, any applications that are exposed on the Internet generally need to be hardened, monitored, and maintained as if they were a production server which also adds to the complexity and level of effort to manage. Given these challenges, many organizations only expose one or two of these pre-production environments, but this greatly limits the ability of developers and testers to test end-to-end early in the development lifecycle.
A new approach
A new and better approach that is both simple and secure has been needed, and that’s where Enterprise Application Access comes in. EAA provides a cloud DMZ service built on the zero trust model; it provides authenticated and authorized application level (L7) access without ever exposing these internal environments to the Internet. EAA’s architecture consists of two components:
EAA Cloud EAA Cloud enforces the following checks: • Authentication (AD/LDAP, SAML, or built-in Cloud Directory) • Authorization (per application) • Optional multi-factor authentication (MFA) • Optional access-control policies
- EAA Enterprise Connector EAA Enterprise Connector is a hardened and headless VM which: • Calls from the inside out to the Akamai cloud on dual-authenticated TLS sessions • Runs on practically any virtual platform (e.g. VMware, Hyper-V, Docker, AWS, Azure, etc.)
EAA architecture allows for end-to-end testing between the Akamai platform and private development or QA environments.
Once a user passes all security checks in the EAA Cloud, these two components act as proxies, enabling secure L7 connectivity between the user and the application. To complete the picture for this development/test use case, the Akamai delivery configuration simply goes forward to EAA as the 'origin' in order to reach the actual origin server on the internal network.
Rapid deployment with minimal setup time
Just as important as the security architecture is the setup time and level of effort to manage. EAA can be deployed from start to finish within minutes and without additional hardware. No IP whitelisting or firewall holes are required. No changes to applications are needed since they remain internal and private. There is integration with existing user/group directories (e.g., Active Directory) for authentication and authorization as well as full RESTful API support.
Additional use cases
I've heard a lot of excitement about this solution recently due to its simplicity in addressing the testing challenges mentioned above, but the benefits and use cases don't stop there. This EAA service can also be leveraged for the following four use cases within these same development teams:
1) Cloud-based test agent access:
- Automated testing tools (e.g., BrowserStack, Perfecto, etc.)
- Load testing through Akamai's CloudTest
2) Content developers accessing CMS
3) Remote developer access to:
- Configuration and deployment tools (e.g., Jenkins)
- Project management and collaboration tools (e.g., Jira, Bitbucket, Confluence, SharePoint, etc.)
- Server/application infrastructure (e.g., web, RDP, SSH)
- Code repositories (e.g., GitHub, SVN)
4) API calls from mobile apps
If you'd like to learn more about EAA, visit theEAA home page.
Shaun Tamblin is a senior solutions engineer at Akamai Technologies.