Skip to content

Use cases

Bifröst can combine SSH authorization with different session environments. The following examples illustrate configurations for specific access problems; their security properties depend on the identity provider, session settings, target permissions and deployment.

  1. Meet a defined off-boarding deadline
  2. On-board users with an identity provider
  3. Bastion Host / Jump Host
  4. Access Kubernetes clusters without publicly exposing their APIs
  5. Isolated Demo/Training environments
  6. Different rules for different user groups per host
  7. Migrating from sshd

Tip

Session recording can preserve signed terminal output, but not raw keyboard input or SFTP/forwarding payloads. An SSH gateway can connect to a target server with a separate authentication step; it does not transparently forward arbitrary SSH requests.

Meet a defined off-boarding deadline

Customer contracts or certification requirements can set an off-boarding deadline, for example 15 or 60 minutes. A requirement to be able to disable remote access is different from proving that a departing person can no longer access any resource within that time after the off-boarding decision. Define which requirement applies and when its clock starts. Bifröst was created in part for this problem: OIDC can centralize new access decisions instead of changing keys on every host.

Put the control in place

  1. Use OIDC Device Authorization so that your IdP can reject new logins after access is withdrawn. By default Bifröst requires a refresh token and checks it while the session is active, including sessions reused with a remembered SSH key. A permanently rejected refresh grant closes the associated Bifröst SSH connections and disposes the session. Check whether disabling a user actually invalidates their refresh grant at your IdP, and when the next verification will run.
  2. Set both ssh.maxTimeout and session.maxTimeout to fit your deadline. Both default to unlimited. For OIDC, also review refreshToken.maxUnverifiedFor: it defaults to 30 minutes before disposal during an IdP outage. The 5m values below illustrate a short time budget; neither idle timeout nor SSH certificate expiry alone ends every active connection.
  3. If the requirement is actual off-boarding, measure from the recorded decision to the last possible access: test new logins and existing shells, SFTP, forwards and downstream access. An IdP change is not necessarily reflected in an existing refresh grant or independent processes on a target. If the deadline cannot be met, add an explicit termination step and test it.
1
2
3
4
ssh:
  maxTimeout: 5m
session:
  maxTimeout: 5m

These are example values, not a claim that adding this snippet guarantees the deadline. Account and process cleanup depends on the selected environment. Validate the complete path, including other login methods and targets, against your organization's actual control. See the OIDC guide for a first login.

If your requirement is only the capability to disable remote access within a deadline, measure that operation separately; it is not proof that every session or credential of a departing person has been revoked.

On-board users via an identity provider

This is the counterpart to off-boarding users, but the IdP, environment and target permissions must all allow the new access.

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 AND NOT in days or weeks?
Often admins have to ask themselves: "Did I really give them access everywhere?"

Solution

Use OIDC authorization with a configured IdP to authenticate the user. A Docker or Kubernetes session does not require a matching local host account; a local environment needs an existing account or explicit provisioning settings.

Check the permissions of the selected environment and any downstream services separately.

Resource creation depends on the environment and its configuration; it is not a universal default.

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 a service inside an AWS private VPC.
  3. You have to manage that service.

The following cases are usually used:

  • You need to start a VPN connection with a VPN server to get a direct connection to this network. Either you have to deal with quirky VPN desktop client software or the 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:
    1. Inside the private network itself (in case of AWS a dedicated EC2 instance for example of instance-type t2.micro)
    2. or outside the network with a fixed VPN connection to get inside the private network.
  2. Configure an appropriate authorization, for example OpenID Connect, and review session reuse and revocation behavior.
  3. For an existing private OpenSSH server, follow the SSH gateway guide. For a separate workspace, choose the Docker environment; its isolation depends on privileges, mounts and runtime access.

Access Kubernetes clusters without publicly exposing their APIs

Problem

  1. Assume you have one or more Kubernetes clusters.
  2. There kubernetes clusters should be accessed by your developers and/or support agents to do development and debugging work.
  3. The people who should access this can be located inside the office (with protected networks) but also in untrusted environments like working from home.

Usually, you either make the Kubernetes cluster's API directly accessible over the internet and secure them with (hopefully) secure secrets or shield them behind firewalls. In these cases every person who wants to access the cluster API then has to use a VPN software to access the cluster's API which also introduce other issues in usability, costs and complexity.

Solution

  1. Have a Bifröst instance inside your protected network, which port 22 is exposed to the internet.
  2. Protect the access with every mechanism you like OpenID Connect.
  3. Pick an OCI/Docker image which holds kubectl.
  4. Configure the kubernetes environment with a kubeconfig which is able to access the Kubernetes cluster inside your network.

As a result your people can use a standard SSH client with OpenID Connect (including a browser verification step) to access a kubectl instance without exposing the cluster API directly to the public internet. The kubeconfig and Pod permissions still determine what they can do.

As a plus, the users accessing this instance have easier access to the resources like databases and rest APIs inside Kubernetes, because they can directly use the cluster internal domain names, instance kubectl port-forward.

Isolated Demo/Training environments

Problem

  1. Assume you want to show how your software can be used (demonstration) or you want to create training sessions for users.
  2. You need an environment where your users can easily have command interaction with.
  3. Each user needs a dedicated and isolated environment.
  4. You want to provide your own set of tools within these environments.

Solution

  1. Choose your favorite authorization mechanism, such as:
    1. OpenID Connect to ensure, that only users are already registered at your application are able to connect to your service or even using public social accounts like GitHub or Google to freely connect to your service.
    2. Maybe you want to use fixed passwords.
    3. Disable any kind of password request, which is only recommended for these kinds of purposes, nothing else. In this case, you can use the none authorization.
  2. Create an OCI/Docker image with the applications you want to show.
  3. Configure the kubernetes environment or the docker environment with a reference to your own image.

Different rules for different user groups 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).

Different rules can also be implemented with other SSH configurations or access platforms; Bifröst expresses the authorization and environment choice through flows.

Solution

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

Migrating from sshd

For local-account SSH access, use the host configuration and installation guide. Bifröst uses port 22, so stop the previous SSH server before starting it.

Test your particular sshd configuration: Bifröst does not implement every OpenSSH extension or authorized_keys option, such as no-touch-required.

More topics