Skip to content

Use cases

As Bifröst is very flexible on how it can be configured (see configuration documentation), here are some use-cases which can be fulfilled by it:

  1. Off-board users within 15 minutes of the organization
  2. On-board users within 15 minutes in the organization
  3. Bastion Host / Jump Host
  4. Different rules for different users per host
  5. Drop-in-Replacement

Tip

We're planning to also implement a Docker and a Kubernetes environment. This will create much more use-cases, soon. 🤠

Off-board users within 15 minutes of the organization

Problem

  1. Assume you're part of an organization.
  2. Assume this organization has more than just 10 people who might be able to access SSH resources.
  3. Assume you've to off-board an employee, now.
  4. Assume it is your job to make sure that this employee cannot do any harm to the organization, because the machines the user is currently on are critical to the technical security of the organization.

In cases of SSH servers, this often results in going through all servers and either:

  • Change the passwords,
  • Remove dedicated users,
  • Remove user's public keys (if you can find out who it is 🤯),
  • or change the Ansible or Puppet configuration and apply it on every machine.

How this should be done within 15 minutes (not days or weeks)?
How do you ensure you really removed this user everywhere?

Solution

Don't ...

  1. ... have users installed on the systems itself.
  2. ... share passwords of shared users or even the root user.
  3. ... have user's public keys stored at shared users or even the root user.

Do

Use the OpenID Connect authorization.

As the users are always authorized by your Identity Provider (IdP) this is always evaluated when someone tries to access the service via SSH. It will also immediately reject the authorization to this service.

No need to access any of these services directly to remove/de-authorize these users.

If the environments are configured accordingly (which is the default) all of the user's files and processes will be removed/killed automatically, too.

On-board users within 15 minutes in the organization

This is quite similar to Off-board users within 15 minutes of the organization, but obviously reverse.

Problem

  1. Assume you're part of an organization.
  2. Assume this organization has more than just 10 people who might be able to access SSH resources.
  3. Assume you need to on-board an employee immediately.
  4. Assume you have to ensure that this employee can access all services with no delay.

In case of SSH servers, this often results in going through all servers and either:

  • Share the server shared-user passwords,
  • Add user's public key to a shared user,
  • Add a dedicated user (with password or authorized key),
  • or changing the Ansible or Puppet configuration and apply it at every machine.

How can this be done quickly (not in days or weeks)?
"Did I really give him access everywhere?"

Solution

Use the OpenID Connect authorization.

There is no need to create them somewhere on the server itself. The OIDC authorization will do that using the configured Identity Provider (IdP) - that's it!

No need to access any of these services directly to create/authorize these users.

If the environments are configured accordingly (which is the default) all of the user's resources (like the home directory) will be created automatically.

Bastion Host / Jump Host

Problem

  1. Assume you have to manage resources.
  2. These resources are not directly accessible to you. They are protected within other networks to which you have no direct access. For example, you're sitting at home and there's another service inside an [AWS private VPC]. (https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html).
  3. You have to manage that service.

The following cases are usually used:

  • You need to start a VPN connection with an VPN server to get a direct connection to this network. Either you have to deal with quirky VPN desktop client software or SSO isn't working (which might only make sense for small organizations).
  • There is a bastion host in-place, based on OpenSSH sshd which will run into on-boarding and off-boarding issues.

Solution

  1. Set up a bastion host either:
  2. Inside the private network itself (in case of AWS a dedicated EC2 instance for example of instance-type t2.micro)
  3. or outside with a fixed VPN connection inside the private network.
  4. Configure your preferred authorization (for example OpenID Connect for best on-boarding and off-boarding experience).

Different rules for different users per host

Problem

  1. Assume you have an SSH server.
  2. Different users should be authorized differently.
  3. Different users should run in different environments (one in a local environment with permission A, another with permission B, and a third user in a remote environment).

This is almost impossible with current technology, except with different OpenSSH sshd setups on a host, or even different hosts, or hacked PAM or shell setups.

Solution

Use Bifröst with multiple flows, configured. Each flow can handle different authorizations and environments.

Drop-in-Replacement

You simply want to use something else than OpenSSH sshd, Bifröst will do this, too. 😉 Just use this configuration.

More topics