Securing cloud console and CLI access for agile software development

September 2, 2025 Sunit Randhawa and Prashant Tyagi

CLI access for agile software development

Fast-moving cloud environments demand speed, but without the right access controls they invite risk. Resources such as virtual machines, containers, and services are created, modified, and terminated at a rapid pace. At the same time, workloads are becoming increasingly distributed, with data and applications spanning multiple regions, accounts, and even across different cloud service providers (CSPs). Ensuring secure access to cloud provider consoles and command line interface (CLI) tools is critical for those responsible for managing and operating infrastructure.

This blog is intended as a guide for cloud operators and technologists who regularly interact with cloud platforms to provision resources, manage configurations, and support development workflows. It outlines best practices that can help secure access to cloud consoles and CLIs, focusing on minimizing standing privileges, enforcing least privilege principles, and maintaining visibility and control across multi-cloud environments.

Every team member potentially holds the keys to critical infrastructure and sensitive data. A single misconfigured identity permission or exposed credential can open the door to breaches, lateral movement, and data compromise. The challenge for organizations is clear: How can they empower teams to move quickly and efficiently in the cloud while maintaining strong access controls, visibility, and governance?

Hidden risks of console and CLI Access

Cloud consoles and CLIs are essential tools for cloud operators and technologists—used daily for provisioning infrastructure, managing services, and supporting deployments. But without the proper guardrails, they introduce serious risks:

  • Over-permissioned: Users are often granted excessive IAM privileges for convenience or speed.
  • Difficult to audit: Console-based actions lack the transparency of API-driven workflows.
  • Challenging to rotate: Static credentials, once exposed, can remain active and undetected.
  • Attractive targets: Login-based access paths are vulnerable to phishing and social engineering attacks.

Even a single misstep or overlooked credential can expose critical systems and data. Without fine-grained access controls, session boundaries, and continuous monitoring, console and CLI access become a high-risk vector in the cloud security posture.

How to reduce cloud access risk with just-in-time workflows

To help mitigate the risks of over-permissioned and unmonitored access—while still enabling productivity—organizations can implement the following access workflow:

  1. Centralized identity federation
    Users authenticate through a centralized identity provider using single sign-on (SSO), which can help deliver consistent identity management across cloud platforms.
  2. Role-based access assignment
    Upon authentication, users dynamically receive cloud role assignments based on their group membership, job function, or project context—enforcing least privilege by default.
  3. Just-in-time (JIT) access provisioning
    Access is granted only when needed, for a defined time window, eliminating standing access and reducing the attack surface.
  4. Abstracted access (credential-less)
    Users interact with cloud consoles and CLIs without handling long-lived credentials or keys. The platform brokers access on their behalf.
  5. Session monitoring, recording, and auditing
    All actions taken during the session—whether in the console or CLI—are recorded, monitored, and logged, providing complete visibility into who did what, when, and for how long.

This left-to-right workflow can help reduce the impact of credential compromise and privilege misuse:

Federation → role assignment → JIT Access → abstracted access → auditing

Even when access is requested frequently, recurring approvals can still result in persistent privileges if not time-bound or tightly scoped. Just-in-time provisioning helps reduce this risk by ensuring access is temporary, task-specific, and automatically revoked—making it a more secure alternative to traditional access models.

This approach lays the foundation for zero standing privileges (ZSP), which represents the lowest-risk model for cloud access.

Why zero standing privileges (ZSP) are critical for cloud security

Zero standing privileges (ZSP) is a security approach that eliminates persistent access rights to sensitive systems and cloud environments. Instead of granting users long-term privileges, ZSP ensures that access is provisioned just-in-time, for a specific task or time window, and is automatically revoked once the session ends.

With ZSP, users cannot access high-risk roles or environments continuously. They carry out routine access with time-limited permissions and gain access to more sensitive functions through explicit approval workflows. All access is ephemeral, auditable, and tightly controlled, dramatically reducing the attack surface and the potential impact of credential compromise or privilege misuse.

ZSP shifts the security model from “always-on access” to “access when needed, for as long as needed—and no longer,” enabling strong security without slowing down operations.

access when needed, for as long as needed—and no longer

Maintaining developer agility without compromising cloud security

Agility for cloud operators is essential, but it must be balanced with strong security.

By implementing the ZSP approach to cloud infrastructure access, organizations can:

  • Reduce standing privileges to zero. Provision access just-in-time, only when needed, and revoke it automatically after use.
  • Eliminate credential sprawl. Broker access through ephemeral, credential-less sessions without exposing long-lived keys.
  • Monitor every session for anomalies. Record and analyze session activity in real time across cloud consoles and CLIs.
  • Meet compliance mandates with full traceability. Maintain detailed, tamper-proof audit logs of who accessed what, when, and for how long.

Developer access control in the cloud: A case study in risk reduction

A typical cloud engineering SCRUM team comprises six to eight developers with different roles focused on DevOps, infrastructure, backend, frontend, analytics and machine learning (ML), and platform engineering. On average, each developer accesses cloud resources 10 times daily through a CLI or console. Cloud engineering solutions organizations typically operate five or six SCRUM teams, meaning the organization may see roughly 450 to 500 access requests daily for cloud resources. As the cloud footprint grows, risk multiplies—roles become intertwined and complexity increases.

To help manage these challenges, the CyberArk engineering team implemented a solution to manage developer access across its cloud environments. Developers are assigned specific roles aligned to their team and environment (e.g., dev, staging, prod), following the same best practices recommended to our customers. The permissions and policies tied to each role are tailored to that team’s responsibilities, supporting a tight least privilege model.

Developers access the cloud console multiple times daily. In contrast, CLI access is secured using eight-hour, time-bound tokens issued by the access platform—eliminating the need for persistent credentials and helping reduce operational risk.

CLI access is secured

Time-bound cloud access: How the workflow works

In the example below, a developer logs into the CyberArk User Identity portal and is part of a policy to access a cloud identity center, securing different accounts and environments. In this instance, the developer is requesting:

  • Two hours of read-only access to the DevOps account
  • Ten hours of read-only access in the development account

With one click, the developer requests access by pressing the “Connect” button, enabling secure access via the cloud provider’s console or CLI for the requested time window only.

user identity portal

AI in software development: Preparing for new security risks

Artificial intelligence (AI) is expected to significantly transform the software development life cycle (SDLC) by automating tasks, improving efficiency, and enhancing decision-making across various phases. However, this integration also introduces new security risks that require careful consideration.

AI’s integration into the SDLC expands the attack surface, creating new vulnerabilities and potential entry points for malicious actors. AI models can be susceptible to adversarial attacks, where manipulated input data can trick the system into making incorrect decisions. Attackers may also attempt to steal or replicate proprietary AI models.

These are just some of the vulnerabilities associated with using AI in the software development lifecycle. Applying a ZSP approach for developers can help safeguard against this increased threat landscape by limiting access to only what is needed, when it is needed, and for no longer than necessary.

Securing developer access in the cloud: What comes next

Developer access is one of the most critical, yet overlooked, cloud security vectors. The convenience of access should not come at the cost of control. It’s time to rethink how access is granted, monitored, and revoked.

By implementing least privilege and JIT access through tools through centralized identity platforms, organizations can protect critical infrastructure while enabling developers to move fast and safely.

Because in the cloud, every key matters. And you should know exactly who has them.

Sunit Randhawa is a cloud solutions strategy architect and Prashant Tyagi is a cloud technical senior director at CyberArk.

No Previous Articles

Next Article
Declutter your crypto: Machine identity security for a post-quantum world
Declutter your crypto: Machine identity security for a post-quantum world

In a bad dream, you open the closet. You think you know exactly what’s in there: a few SSH keys, a bunch of...