BLOG POST

Getting To Cloud Native Authz

 

July 11, 2014 | DevOps | Kevin O'Brien

 

Cloud Native Authz

At the AWS Summit in New York City this week, one of the major themes woven into the keynote (as well as many of the other presentations) was the idea that companies and the people within them who truly understand the value of DevOps/continuous integration/disruptive innovation should be seeking “cloud native” partners, vendors, and platforms.

In part, cloud nativity is simply a pointer, indicative of organizations who build, think, and execute differently from their peers who were born in a different era. It is, in other words, a means of identifying those organizations that believe in (or at least buy into) the same conceptual frame work.

We like to believe that we (and Conjur the product) are “cloud native”. As Elizabeth often points out, our earliest roots are born in frustration when innovation at a previous employer was hampered by a lack of cloud-ready authorization services – a problem we are 100% focused on solving. Part of the challenge in doing so is that many of our friends in the industry are still figuring out how to describe the differences between authentication and authorization (see our recent blog on this subject.)

More broadly challenging is that DevOps and cloud-first initiatives are terra incognita for most companies who were not founded within the last few years. Cloud computing, especially at the infrastructure level, is fundamentally changing how organizations source, host, and manage applications, data, and workflow, and finding vendors and solutions that are built with this new infrastructure in mind can be daunting; many companies hack together solutions where vendors have not yet provided them, or where the requirements that reflect a truly well-designed solution are not yet clearly defined.

07_11_14

Of course, that’s not a great way to handle something as mission-critical as authorization. In claiming that Conjur is “cloud native authz”, we are looking to help clarify how to think about and manage authorization in the new infrastructure stack – something that we have heard called the Cloud OS from vendors like Microsoft, and which others refer to as the “cloud stack” (see, for example, Amazon’s new Zocalo announcement, broadly focused on an enterprise-friendly use case for cloud storage) – without relying on hacks and kludges.

In a nutshell, we believe that any robust “cloud native authz” platform should embody three characteristics:

  • Extensibility: The platform selected should quickly adapt to a wide and (at best) loosely undefined set of different infrastructure and platform decisions; organizational needs will change over time, and no assumptions should be made regarding what the environment will look like from month to month, or even day to day. Any authorization platform used should be capable of abstractly supporting any platform/system in order to remain relevant and usable across even foundational architecture changes.
  • Efficiency: Core authorization concepts (tokens, user-to-server and service-to-service management, etc.) all need to be implemented securely; look for a solution that doesn’t require extensive in-house coding or scripting of these core features, and is ready to use out-of-the-box. Avoid the temptation to build something entirely in-house, as it creates a long-tail of support as well as a significant up-front development cost (or worse, an unknown cost as scripts, configuration management systems, and repositories are shoehorned into roles that directly contradict their fundamental design objectives).
  • Scalability: Assuming that organizations that are looking for “cloud native” solutions are also believers in continuous integration and rapid iteration philosophies, the authz provider they select must be capable of coping with rapid and high-volume change in very short timeframes; look for solutions with robust master/follower architectures that can both provide a single system of record and a rapid distribution model for public information (without relying on, for example, configuration management tools to do so). There are likely more bullets to be added to this list over the coming months. Topics such as native auditability (which Conjur supports out of the box, removing the need to hand-crank audit reports as most organizations do today), a finer distinction between deployment time for development vs. operations (again, Conjur is ready to use almost immediately for both departments), and end-to-end automation are still being worked out with our customers, but we believe there is a growing consensus around what well-built cloud native authz will look like.
    <!– [if lte IE 8]>

    <![endif]–>Download the Conjur Data Sheet!  

    This is a tremendously exciting and quickly evolving space, and we’d love to hear what you’re seeing, struggling with, and succeeding at within it.

    Drop us a line, or have a look at our one-page sheet describing how Conjur works today.

 

 

Share This