Providers

Glide consists of two components: the Core Framework and Access Providers.

The Core Framework is the access approval engine, and handles the workflows around granting and revoking access.

Access Providers are plugins for Glide which provide access to roles and resources. Examples of Access Providers are an AWS Access Provider or an Okta Access Provider. Access Providers contain specific integration logic to assign users to resources.

You can get started by adding your first provider. This will walk you through how to add a test provider, helping you understand the access workflow before connecting your production environments.

​

Provider List

• AWS CloudWatch Log Groups
• AWS SSO (Built-In Provider)
• Azure AD Groups (Built-In Provider)
• ECS Exec (Built-In Provider)
• Okta Groups (Built-In Provider)

​

Upgrade advice from Glide v0.14 and earlier

In Glide v0.14 and earlier, a set of Access Providers were included in the Glide deployment. These are referred to as Built-In Providers.

In Glide v0.15+, Access Providers are versioned and deployed separately to the Glide deployment, and are developed using a library called the Provider Development Kit (PDK). These are referred to as PDK Providers. Glide v0.15 also supports the existing Built-In Providers.

If you are currently using Built-In Providers (such as AWS SSO or Okta Groups Access Providers), no action is currently required, and your Glide deployment will work as-usual when updating to v0.15.

It is intended for Built-In Providers to be deprecated in favor of PDK Providers within the next few releases. Documentation will be published on how to migrate from Built-In Providers to PDK Providers, without causing downtime in your deployment.

​

Provider Registry

Providers are published to the Provider Registry at https://api.registry.commonfate.io.