Available

Apps and cloud access · in Professional and Enterprise

Access to clouds and servers, with no keys to leak.

One grant decides who may open an application, assume a cloud role or reach a server. What they receive lasts minutes, so there is nothing long-lived to steal.

The Cloud Access page: three cloud accounts and the roles found in them.

Cloud roles, with no stored keys

AuthFI decides who is granted a role. The cloud decides, when the role is assumed, whether to honour it. This page shows where the two disagree.

One model

The same grant, whatever it opens.

Add someone to a group and their access follows within seconds. Remove them and their next sign-in, token, certificate or cloud credential is refused.

What is grantedHow it is reachedWhy it is safer

An application

Open only to the groups assigned to itChecked every time a token is issued

A cloud role

Assumed for minutes, by a person or an agentNo access key is ever stored

A server

Reached with a certificate that lasts minutesNo shared key on the host

A command on that server

Allowed, refused, or allowed after a fresh second stepDecided on the host itself

Keyless cloud federation

Cloud roles for people and agents, with nothing stored.

Your cloud account trusts your AuthFI project. A person or an agent that holds a grant exchanges its AuthFI token for credentials that last minutes.

AuthFI finds the roles in each account and checks that each can still be assumed

A grant can carry an end date, and lapses on its own

Works with AWS and Google Cloud

Cloud Access: accounts, roles discovered, roles granted and roles that can no longer be assumed.Cloud Access: accounts, roles discovered, roles granted and roles that can no longer be assumed.

The trust is standard workload identity federation: sts:AssumeRoleWithWebIdentity on AWS, workload identity pools on Google Cloud.

Keyless roles on

AWSGoogle Cloud

Server access

Linux servers, reached with certificates that last minutes.

Nobody holds a key to a server. A person who was granted access receives a certificate for one session, signed by your project’s own authority.

The server trusts one authority, not a list of keys

Access follows the same groups as everything else

Every session is on the record

The Servers page: six targets, who may connect, and whether privileged-command rules are enforced on each.The Servers page: six targets, who may connect, and whether privileged-command rules are enforced on each.
Pilot

Privileged commands

Decide what may be run as root.

Rules for privileged commands are written once and apply on every governed host: allow, refuse, or ask for a fresh second step. The console says, per host, whether the rule can actually bite there.

The privileged-command rules: who may run which command, and with what condition.The privileged-command rules: who may run which command, and with what condition.

Connections

Everything the project is wired to, on one page.

Where people sign in from, where the record is sent, how people are reached, and the tools your agents use.

Identity providers over SAML and OpenID Connect

Log tools such as Splunk, and alerting such as PagerDuty

Email and text gateways, and your own webhooks

The Connections page, grouped by what each connection is for.The Connections page, grouped by what each connection is for.

Where each part stands.

Application access by group

Available

Connections to providers, log tools and gateways

Available

Keyless roles on AWS

Available

Keyless roles on Google Cloud

Available

Finding which roles exist and which still work

Available

Server access with short-lived certificates

Available

Rules for privileged commands on the host

Pilot

Session recording

Pilot

Database and Kubernetes access

In development

Delete your last long-lived cloud key.