Apono partnership brings just-in-time access to Elasticsearch and Elastic Cloud

Elad Plachzinsky

Technical Product Manager

August 19, 2026

Apono partnership brings just-in-time access to Elasticsearch and Elastic Cloud post thumbnail

Pull an access review on almost any Elasticsearch cluster and you’ll find the same thing: roles created for a migration two years ago, analyst accounts with broad read access to indices they queried exactly once, and service accounts nobody can quite explain. None of it was granted carelessly, and all of it is still there.

That leftover access is the problem. Search and analytics environments hold some of the most sensitive data in the stack, including logs, metrics, customer records, and the indices behind observability and security operations. Every account that outlives its purpose is a standing privilege an attacker or a careless insider can use.

Elastic already gives teams the tools to prevent this with native role-based access control (RBAC) across Elastic Cloud and Elasticsearch, which lets teams define exactly what a role can touch. The gap isn’t the access model, but rather the challenge of keeping role assignments current as fast as the roles themselves are defined. With our integrations with both Elastic products, Apono now automates that lifecycle: access is created at the moment of request, scoped to the task using Elastic’s own roles, and deprovisioned automatically when the work is done, leaving behind no standing access.

The problem: RBAC assignments that outlive their purpose

Elasticsearch and Elastic Cloud environments accumulate access the way most technical debt does, gradually and for good reasons. Engineers keep the admin rights they were granted during an incident, analysts hold onto broad index access they needed only once, and project roles linger long after the project ends. RBAC still defines exactly what each of those roles can do, the roles just outlive the task they were assigned for.

When the data itself is regulated, the stakes climb: proving who had access to what, and for how long, becomes a manual exercise that security and compliance teams repeat every quarter.

This pattern is not an edge case. Standing access is both over-broad and under-governed, and it concentrates exactly where visibility is lowest. Our internal analysis of customer data shows 96-99% of standing access is unused, meaning that it’s just sitting there as exposed attack surface with no benefit to the organization.

How it works together

Apono connects to Elasticsearch and Elastic Cloud to continuously discover roles, indices, clusters, and deployments as they’re created. Once discovered, those resources become available inside access workflows, so teams can define who can request what, under what conditions, and for how long.

What makes this different from a standing-role model is where the access is created. Rather than routing engineers through a proxy or a bastion host, Apono creates access using Elastic’s own RBAC roles in the native policy language of the target system at the moment of request, then removes it when the session closes. A user who needs read-only access to a production cluster – be it a backend engineer, data engineer, data analyst, etc., – can request it, have it auto-approve by policy when the request is low-risk, and have it revoked automatically when the session ends.

Higher-risk requests, like admin access to an Elastic Cloud deployment, route to a human reviewer first. Either way, the grant is scoped, time-bound, and logged from the moment it’s approved.

That combination gives joint customers three things:

Context-aware access: Apono scopes permissions to the specific role, index, cluster, or deployment a person actually needs, not the broadest role available.
Speed without a queue: Low-risk requests clear automatically by policy, so engineers get what they need in minutes instead of waiting days for a manual review.
Audit-ready records: It logs every grant with who requested it, who or what approved it, and when it was revoked, which turns an access review into a report instead of a research project.

Teams running Elastic tell us they want the operational simplicity of Elastic’s managed services without giving up control over who can reach the data inside them. This integration is built for exactly that.

Part of 1Password Unified Access

Going forward, Apono will be part of the 1Password Unified Access platform that will further enhance the strength of the Elastic integration:

Enterprise Password Manager stores and manages the credentials your people use. 1Password
Credential Broker delivers secrets to workloads at runtime
Apono (aka 1Password Privileged Access) governs what those identities are permitted to do in the systems they connect to, when, and for how long.

For an organization with a full privileged-access mandate, the three work together to cover the credential, its runtime delivery, and the access rights in the target system. For teams already standardized on 1Password, extending that same trust model to Elastic means one trusted vendor for identity and access across people, machine workloads, and AI agents, without ripping and replacing existing IAM infrastructure.

What this means for customers on both sides

If you already use Elasticsearch or Elastic Cloud, the integration is available through the standard Apono connector setup. Your Elastic roles and resources appear automatically once connected, and existing access policies extend to cover them without extra configuration.

If you run Elastic and are evaluating how to tighten access governance around your deployments, this is a path toward automating the RBAC roles you’ve already built, so access exists only as long as the work requires it, without adding friction for the teams who depend on fast access to search and analytics data. And for Apono customers evaluating Elastic Cloud or Elasticsearch, this provides further peace of mind that you can continue to enforce zero standing privileges across your critical environments, reducing your attack surface while keeping your internal developers and engineers happy and productive.

Getting started

Setup takes three steps: connect Apono to your Elasticsearch or Elastic Cloud environment, build an access workflow that matches your policies, and let your team request access on demand.