How to standardize authorization policy management of your network and applications
“The evolution of policy management must include applications
and their supporting frameworks such as Kubernetes
with public cloud, microservices, and APIs.”
As a driver we often take for granted our driver’s license – unless you’re one of my twin 16-year-old daughters! 😊
In states and countries with reciprocal agreements driver’s licenses allow the authority to use public motorways and define privilege levels or endorsements, such as private automobile, motorcycle, commercial truck, etc. Imagine a world where this authorization was not defined uniformly or applied reciprocally – it would be very inconvenient to need to get new authorization credentials every time we crossed a state or country boundary!
Network Infrastructure architects, developers, and administrators are probably familiar with the policy management functions in the Cisco ACI data center solutions, Cisco’s Identity Services Engine (ISE), and Cisco Policy Suite. They enable Zero-Trust Security, SD-WAN, and mobility services. By extension the evolution of policy management must include applications and their supporting frameworks, such as Kubernetes with public cloud, microservices, and APIs.
Join the policy management of your network infrastructure with that of your applications
Cisco realized the need to join the policy management of the network infrastructure with that of applications riding in layers above. The idea of “if you’re authenticated, you have carte blanche access” is long past. More secure and sophisticated environments must operate on the principle of least privilege. The transition to more controlled access may feel as if it stifles innovation and progress, but it doesn’t have to! A software developer may embrace agile software development principles, but it doesn’t excuse them from security best practices. Their users and customers expect a frictionless experience, but security should be ever-present. Ideally the customer experience (CX) becomes a differentiator.
The Advent of the Open Policy Agent (OPA)
Moving away from overly broad and privileged access requires is a different approach. The industry recognized the inefficiency of having many bespoke authorization systems and the lack of standardization in applying policy. The Open Policy Agent (OPA) was born as a general-purpose policy engine, decoupling policy decision-making from policy enforcement.
Through mutual interest, Cisco and Styra started the OPA project back in the summer of 2018. Styra donated OPA to the Cloud Native Computing Foundation (CNCF) (the governance body for all cloud-native open-source projects) in March 2018. Within three years of open scrutiny by industry leaders, OPA became the 15th open-source project and the first focused on authorization to reach ‘Graduated Project’ status.
Automated policy integrations across public clouds
With OPA, a developer-administrator manages policy decisions for Kubernetes and microservices through automated policy integrations across public clouds thanks to its single, unified policy language. Think of it as ‘policy-as-code’, as seen in this image.
The prospects for developers, especially cross-domain ones, are very exciting as we glue together these systems! The network infrastructure together with the application layer in policy harmony is a reality.
OPA Advantages
OPA was created to be used by a policy administrator or software developer. It addresses challenging areas in authorization policy management:
- How do you write and express authorization policy?
- How do you provide a policy engine that makes decisions using a policy file?
- How do you debug policy or check performance?
- How do you integrate with external software?
The policy file above defines the authorization services and parameters in an easy to read and programmatically convenient YAML file format. These files can be created, modified and exchanged through software programs making the policy architecture more automated. From a maintenance standpoint the policy files can be version controlled, archived and reviewed in a git repo. From an operational perspective the environment could be deployed in Docker containers managed with Kubernetes for extreme resiliency and performance.
Scaling Policy Management and Operations
Once organizations realize the benefits of standardized authorization policy management, the next logical consideration is scaling it. Styra has the Declarative Authorization Service (DAS) to operationalize OPA for the enterprise without having to spend the time and resources building from scratch. It provides native support for the most popular OPA integrations and keeps them updated to support new versions of software. The list of integrations expands all the time, and includes Kubernetes Admission Control, microservices, cloud configuration and more.
This reduces your effort in integration, enforcement, performance, versioning, and roll-out activities. By implementing Styra DAS, policy structure and pre-built rules are already included so you know which controls an integration provides. If you have further interest, try out Styra’s DAS free at https://www.styra.com/das-free.
Hopefully you can imagine an inkling of what the future holds as we meld network infrastructure authorization policy together with application layer policy. This vision is why Cisco partners with Styra and is another example of “The Bridge to Possible”.
Cisco Developer Relations is committed to enabling the developer community and we believe Styra is too.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel
Share: