DevOps Security: Cloud Secrets Management, from Multi-Cloud to Cloud Agnostic Environments

Organizations are migrating and deploying new workloads in cloud environments much more rapidly than ever, instead of expanding traditional on-premises data centers. These public cloud environments offer scalability, elasticity, flexibility, and built-in security benefits.

Many organizations have already started or are planning the next phase of their cloud journey:  moving to multi-cloud environments involving multiple cloud vendors. To avoid vendor lock-in (becoming so dependent on a single cloud provider that it is complicated and costly to switch vendors), many organizations use loosely-coupled systems to spread applications across providers.

Organizations also use multi-cloud for technical solutions available in one cloud but not in another, non-technical preference, and compliance regulations. Running workloads in the cloud also has a big budget incentive for DevOps teams.

In fact, multi-cloud deployments have many benefits. Containerized applications, running on a common Kubernetes platform, are probably among the most common items deployed across multiple vendors. Since containers provide flexibility and easily move across platforms, organizations depend less on the cloud vendor.

However, multi-cloud architectures do present several challenges. Think of the multi-vendor knowledge your IT teams need and consider the additional management and monitoring overhead across multiple environments. Even more importantly, how do you streamline secrets management across the different environments you use to maintain DevOps security (DevSecOps)?

In this post, we will look at the risk of managing secrets in different cloud scenarios and discover how CyberArk Conjur mitigates these security challenges with a cloud agnostic approach to managing secrets.

Multi-Cloud Security

Organizations are migrating systems, applications, and data from on-premises data centers to public cloud environments. Sensitive data, formerly stored inside private data centers, is now on the cloud. This sensitive data is appealing to attackers. The systems and applications also often contain secrets (user accounts, passwords, and the like), which also move into the cloud out of the rapid lift and shift migration scenarios.

This poses a major DevOps security risk. Where before these secrets were only stored inside the private data center, they are now exposed across different cloud platforms. You shouldn’t always question the security aspect – cloud platforms like Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP) all take security seriously. The overall security management your internal IT administrators and DevSecOps need to apply could be the main security risk here. How do you keep track of secrets? How do you guarantee the secrets are in sync across all cloud platforms you use? How do you avoid secrets leakage?

Let’s zoom in on the three main cloud-adoption scenarios and discover where the security risk of managing secrets exists today.

Lift and Shift

Lift and shift refers to migrating on-premises workloads to a cloud-based architecture, without changing the architecture. This typically occurs in an infrastructure-as-a-service (IaaS) design, where on-premises virtual machines are migrated into a public cloud virtual machine, networking, and storage architecture. Important here is the “without making any changes” aspect.

On-premises data center security typically orients around firewalls and (often complex) network segmentation and isolation, so it sometimes provides a false sense of security with some applications having minimal security.

In particular, having hard-coded identities or minimal authentication isn’t a particular problem in a self-contained data center. When DevOps migrates these workloads to a public cloud environment where the network security layer isn’t always identical to how it worked on-premises, it can expose your application identities and corresponding secrets to a security risk.

Given all the work needed for lift and shift, it is the perfect time for DevSecOps to remove hard-coded credentials, if you have not already addressed this security weakness, and incorporate secrets management.

To address this, CyberArk’s Conjur, available as either an open source or enterprise edition, manages application identities in your infrastructure:

• It increases infrastructure security by adding secrets management and eliminating hardcoded credentials.
• It centralizes your secrets management in mixed and hybrid environments and offers a clear path from on-premises, to hybrid, to native cloud environments.
• When preparing to lift and shift current infrastructure architectures, secrets management adds a layer of security while still being part of the larger rewrite and testing effort.

Cloud Native

A second approach to running applications in a public cloud platform is cloud native. Compared to lift and shift, cloud native requires rewriting or creating new applications. These could run in container-based architectures, using microservices or using the cloud vendor’s platform-as-a-service (PaaS) capabilities.

Developing new or rewriting existing applications enables DevSecOps to design robust secrets management from the start and take advantage of centrally-managing secrets across the entire infrastructure. To address this, CyberArk’s Conjur helps by:

• Offering strong authentication by leveraging native cloud infrastructure capabilities (IaaS) across platform services (PaaS) as well as containers and microservices.
• Integrating into your existing traditional DevOps tools, but dramatically optimizing secrets handling within a simplified CI/CD pipeline.
• Enabling DevSecOps to leverage centralized, consistent secrets management across their compute environment, spanning on-premises, hybrid, and public cloud.

Moving From Multi-Cloud to Cloud Agnostic

A 100 percent multi-cloud scenario presents the biggest secrets-management challenge since each cloud is essentially its own island of identity. DevSecOps need a centralized mechanism to tie together identities, policies, audits, and other security functions across multiple cloud and on-premise domains.  The solution is cloud agnostic secrets management that works across multiple cloud environments no matter how many cloud deployments or cloud vendors you use.

CyberArk Conjur is a cloud agnostic secrets management solution that addresses the challenges of using multiple cloud providers with the following core capabilities:

• Managing identity across multiple cloud environments
• Extending the identity established by cloud providers
• Centralizing policy, audit log, and secrets rotation management

In addition, this cloud secrets management solution:

• Provides a single source of truth for all the organization’s credentials and secrets
• Improves DevOps security by eliminating secret zero and providing granular identity control
• Supports cloud transformation, especially in multi-cloud environments looking to become cloud agnostic

Cloud Agnostic Secrets Management Example: Azure and AWS

Let’s look at a more concrete example of how cloud agnostic secrets can be shared across multiple cloud environments, for example, where an organization is using both Microsoft Azure and AWS, the two biggest cloud providers.

Microsoft Azure integrates with the Azure Active Directory (Azure AD) identity solution, which in turn shares functionality with the Active Directory software many organizations have been using for years. Azure AD is the cornerstone of how Azure handles identity, application secrets, and access management. Azure is attractive to DevOps working in traditional on-premises environments.

From the Azure Active Directory portal, an organization can manage the different core Identity related subjects, like Users and Groups, cloud-only or hybrid by using Azure AD Connect, a directory synchronization tool between on-premises Active Directory and Azure Active Directory. To integrate applications with Azure AD, you can define app registrations, creating Service Principals or Managed Identities. Service Principals are typically used when 3rd party applications need to interact with Azure, for example when running Azure deployments. Managed Identities is what you would use to avoid managing secrets across Azure resources, like an Azure Virtual Machine connecting to Azure Storage Account Blob Storage.

AWS is the leader in cloud development, particularly Agile and DevOps strategies. It uses its own identity and access management (IAM) solution, enabling user and group creation, specifying how the authentication is handled.

From the IAM management console within the AWS portal, one can manage Groups and Users, as well as defining IAM Roles. IAM roles are a secure way to grant permissions to entities that you trust. Examples of entities include the following:

• IAM user in another account
• Application code running on an EC2 instance that needs to perform actions on AWS resources
• An AWS service that needs to act on resources in your account to provide its features
• Users from a corporate directory who use identity federation with SAML

IAM roles issue keys that are valid for short durations, making them a more secure way to grant access.

Although both cloud vendors use their own solution to manage identity and secrets, Conjur manages secrets across both environments with relative ease. For a more detailed overview of the deployment and configuration steps, read Conjur’s blog post about connecting to AWS and Azure.

The process is straightforward:

Start by deploying the Conjur solution on an Azure Linux virtual machine (VM) using the Conjur Docker-compose container. Then, install Conjur CLI, the command line management tool, to interact with the Conjur Server. This should be installed on your local machine or could be executed on the Azure Linux VM you use to host the Conjur containers.

Now create the policies that govern secrets management across the hybrid cloud environment. Create Conjur Policies outlining group and admin structure.

Create Conjur Policies for different environments (such as development, test, or production and AWS or Azure).

Also define Conjur Policies for different applications across different clouds.

The Conjur policy resource provides a way to organize the other resources (hosts, users, and variables) in a logical way. A policy has an identifying ID attribute that creates a policy namespace for organizing resources. For example, you can create a set of users, hosts, and variables that belong to a specific policy and not to other policies.

Rather than a flat structure of policy, you can organize resources into separate namespaces to create a branching tree of policy. The policy tree structure starts from the “root” policy, which is the default. Underneath, you can create additional policies. Policies can be linked with other policies within the structure, building up a hierarchy.

Within a policy, you define users, groups, hosts, variables and other settings that can be applied to your cloud resources later on. For example, the group “Network Admins” from Azure Active Directory or AWS IAM can only manage Azure Network Resources or AWS Network Resources types.

More information about Conjur Policies can be found under Policy Syntax in the Conjur documentation.

A sample policy for the Network Admin scenario just mentioned could look like this:

- !policy
  id: network-admins
  body:
    - &variables
      - !variable VNET
      - !variable VPC

    - !group network-admins

    # network-admins can read and execute
    - !permit
      resource: *variables
      privileges: [ read, execute ]
      role: !group network-admins

We define the policy id, in this case called network-admins.

Next, we specify two variables referring to Azure Virtual Network (VNET) and AWS Networking resources (VPC). That’s followed by defining which of the security groups are to be used.

In the last section, we specify that the network-admins group can read and execute changes to the corresponding (network) objects.

Note that, besides this network-admin policy, you would also create a user/group policy file in which you specify which users or groups from Azure AD and which users or groups from AWS belong to the network-admin group in Conjur. This policy file is also where the encrypted credentials from each object will be registered.

Finally, you’ll define and consume secrets, based on the policy definitions created earlier.

Conjur’s strong integration capability into continuous integration/continuous delivery (CI/CD) DevOps pipelines enables you to automate this process end-to-end.

With the above steps configured, an application on Azure can now access secrets that enable it to gain, say, database access, while another application on AWS is accessing those same database secrets. Meanwhile, you control all your DevOps security in one handy location.

Next Steps

This article described some of the challenges of using multi-cloud environments, especially around managing identities, credentials, and application secrets. These challenges differ depending on methodology and strategy, like lift and shift, cloud-native, or multi-cloud.

Organizations are under increasing pressure to rapidly adopt cloud environments and upgrade applications. As you transition from an on-premise, to hybrid, to cloud-native environment, and to multi-cloud. At the same time, you want to avoid vendor lock-in and running everything on a single provider — or duplicating security efforts across every cloud platform. Managing secrets is important to maintain DevOps security.

CyberArk Conjur, available in both an open-source and enterprise-level solution, is an easy way to manage your secrets and enable their use across multiple cloud vendor platforms. Check out Conjur to adopt centralized secret management as you embark on your multi-cloud journey.