Okta sponsored this post.
Although it has tended to be treated as something of an afterthought, the last year of remote work has made it clear that identity — from user accounts to privileged admin accounts and machine identities like credentials, certificates and secrets — is a key pillar of infrastructure and DevOps.
“Identity has become a true primary cloud — just as important as your other primary clouds like your infrastructure or your collaboration clouds. It’s also the secure epicenter of your organization’s technology connections,” said Okta CEO Todd McKinnon in his keynote for Oktane21, Okta‘s recent annual user conference, held virtually.
While identity is too important to be neglected, developers are a critical and scarce resource and are often already juggling DevOps responsibilities as well as handling development at all layers of the stack. They need to deal with user identities, identity for resources and the infrastructure they run on, for deployment and securing APIs.
“There just aren’t enough developers and those developers are sometimes wearing multiple hats,” John Pritchard, Okta developer relations vice president, told us, noting that usually, the tools for managing identity in each context are different, and not well integrated with standard developer tools.
Multiple Tools, Same Platform
At this year’s conference, Okta launched a new Developer Starter Edition to make it easier for developers to start using Okta’s identity platform. The company also unveiled a redesigned console, new docs and sample apps to help developers get up-and-running fast, and new integrations with DevOps and API security tools.
Okta also unveiled a new workflow tool plus identity governance, as well as risk analysis and privilege management services that extend the range of what developers can do without needing to become experts in identity.
Workflows for Customer Identity is a low-code visual interface that will be useful to citizen developers building customer-facing applications (whether that’s B2C or B2B), giving them access to the same Okta Integration Network that developers use for pre-configured integrations with DevOps, SecOps and API security tools. Someone in the marketing team can use a drag and drop visual tool to create a workflow using Hubspot, Salesforce, Marketo and SendGrid, while the developer creating a Heroku app can use the Okta platform to add identity directly from the Heroku CLI, and they both get the benefit of the policies and protections the organization has set up.
The authentication flow for an app can trigger backend integrations based on customer behavior — like pulling in personalized offers from a marketing system or customizing the login experience based on the type of account people are logging in with. Or it can call the new Risk Ecosystem API, which uses behavioral and transactional signals from third-party web application firewalls for fraud and bot detection tools like Fastly, HUMAN, F5 Networks, and PerimeterX.
Although this is an API that fits well into cloud native event-driven architectures, Pritchard suggests that the SecOps team will be the experts in interpreting the signals. “Developers will look to the SecOps professional to say ‘what does this behavior indicate, what are the scenarios I need to account for’ and then that can be done programmatically,” Pritchard said.
A Marriage of Identity and Privilege Management
Identity governance is traditionally part of compliance and risk discussions. It’s something you don’t think about until there’s an audit or an e-discovery request, but it’s fundamentally the same question of who should have access to what resources and when. And although it’s usually treated completely separately from managing admin access, it actually goes hand in hand with privilege management. While Okta offers new services for each of them, Pritchard expects them to be increasingly adopted together.
Covering hybrid and multicloud infrastructure resources in a single control plane, Okta Privileged Access is a timely offering. Keyfactor’s recent “State of Machine Identity Management Report” suggests that organizations are struggling with policy governance and best practices for managing the keys, certificates and secrets that secure connections to servers, cloud workloads and IoT devices. Eighty-eight percent reported at least one outage caused expired certificates in the last two years, over half don’t have an accurate inventory of SSH credentials and a worrying number store code-signing keys on build servers and developer systems.
Privileged Access simplifies self-service, time-limited access to ephemeral cloud resources so DevOps or SRE teams can update and monitor systems without the risk of permanent access (or some admin having to take the time to remove admin access privileges manually after every incident). That could be jumping on Slack to ask for access to a database server so you can restart SQL and turn on logging to check that the problem is fixed or handling privileged infrastructure credentials in Kubernetes clusters.
Zoom’s explosive growth over the past year, going from 10 million users per day to over 300 million when life and work suddenly shifted online, is a prime use case for Okta’s Privileged Access. When much of the world went into lockdown in the spring of 2020, Zoom took a platform that was running almost exclusively in its own data centers to the public cloud. At the same time, their visibility and growth made them a target for hackers.
“We had a lot of controls around our authentication infrastructure for the backend. But when we grew at such a quick pace, we outgrew the tools we were using previously,” Zak Peirce, head of data center operations at Zoom, said during a presentation at Oktane21. They had to rethink their server IAM and automation tooling and turned to Okta, which allowed Zoom to scale its team and remain secure, he said.
“I just want my team to be able to install a client… configure it on their laptop and they are able to SSH to the servers with almost no changes,” Peirce said. “Whereas previously they would have had their public/private key pair that was issued by an administrator. Now they just have their credentials with Okta that are provided to them at onboarding. The workflow change was one browser window and that’s it… so very limited changes for the administrators in order to do their work.”
The policy for how resources are managed will have been defined by the security team and they grant just-in-time, time-bound access to make those specific changes.
Identity governance integrates many of the previously point-to-point integrations between identity proofing providers and marketing technology systems, which opens the policy decisions around things like customer acquisition up to more people who have different priorities.
The marketing team cares most about making customer signup fast and frictionless; the security team wants to make sure specific steps in the process are being verified. While agreeing on the right balance for the identity governance policy, they can address more sophisticated questions like different data regulations or extra personalization that can make the signup process more engaging. “They could jointly model where you’ve got GDPR requirements or citizenship requirements,” Pritchard suggested.
But it also leverages the same patterns as handling identity in other areas, Pritchard noted.
Like the risk analysis, doing governance through services in an identity platform that developers consume can be part of a “shift left” approach, one which avoids the delays common with a final security review.
“This makes it more efficient because you engage security professionals much sooner and they get to do what they do best, which is think about managing risk and enforcing policy, and then allow it to be expressed programmatically with all the resources that the DevOps team are looking to make changes against — without making it a ticketing system or all the things that we have to suffer through where automation is just one part of what you have to do so you send a request in and wait,” Pritchard said.
Putting the I in CI/CD
Okta unveiled some specific integrations for cloud native infrastructure, to fit the “as-code” automation pattern where policy is authored in an identity provider like Okta and expressed in an API gateway like Kong. The infrastructure can be securely deployed through CI/CD pipelines with tools like Terraform, to make it easier to manage identity across different environments like QA, staging, production, especially “in a zero-trust environment where service to service and container to container is inherently untrusted.”
Rather than operators having to populate, sync and configure user identities in all those environments, it should be automated as part of the CI/CD pipeline like the rest of the stack, offering repeatability and taking the human out of the loop. But it also leverages the same patterns and policies as handling identity in other areas, whether that’s an identity gateway at the edge, an ingress controller or a service mesh, Pritchard noted.
“If we do this right, we have these different enforcement points where that policy can be enacted; that could be a gateway at the edge or a controller inside of a pod,” he said. “There’s all these different echelons where the security identity stuff is happening and there’s different technology that enforces it but if we can get consistent about how we express it, and the tooling that allows the people that make those policies to find that in one place, then, then we’ve got it right.”
TNS Editorial and Marketing Director Libby Clark contributed to this post.
Images courtesy of Okta.