Overview

Before we getting started, we need to understand authentication in Akeyless. We grant users and services access to Akeyless by creating an authentication method for them. The most important part of this auth method is the way that the people or services authenticate - SAML, OIDC, etc… Akeyless has a number of options but our choice will be determined by our environment. We want to use authentication methods that rely on temporary credentials already present in the system we’re trying to authenticate. In particular, we’ll focus on these:

1. AWS IAM
2. OAuth2
3. SAML
4. Universal Identity

AWS IAM

Akeyless supports IAM auth for all the major cloud providers, but we’re using AWS so we’ll naturally be using AWS IAM auth. The idea with IAM auth is that you turn your cloud privder into a trusted 3rd party identity provider. In essence, you tell Akeyless “Please allow any infrastructure that has this AWS role to authenticate to Akeyless”. You then tell Akeyless what that infrastructure is allowed to access. This is an extremely simple way to connect cloud resources to Akeyless without creating static credentials. Since we’ll be using AWS to host our infrastructure for this project, we’ll obviously be using AWS IAM auth extensively in this project.

OAuth2

OAuth2 (which uses JWTs) has an important niche in our setup. We will use it to authenticate Github Actions. This works because Github generates a signed JWT for each running job and publishes their public key online. This allows Akeyless to validate JWTs coming from Github actions and grant access based on the claims in the JWT. In practice, this means that we can grant access based on things like the owner, the repository, the branch, the workflow, or anything else in the JWT claims.

SAML

Of course SAML is a mainstay for authenticating people. With Akeyless, we can use SAML to login to the UI, but we can also use it to log into the CLI and SDK. This will allow developers to interact with Akeyless programmatically from their development machines with ease. As we’ll see, this ends up being a very helpful feature when it comes to ongoing development and maintenance.

Universal Identity

Universal identity fills a critical niche in most organizations. In short, universal identity provides an easy fall back for infrastructure that isn’t supported by IAM/cloud identity authentication. Universal identity is, in essence, very similar to an API key login since it is basically a long random string (i.e. a token) used for authentication. However, rather than having a static token, the universal identity token is intended to rotate frequently. You can easily configure your infrastructure to rotate its token once every minute, which means that a stolen token is almost immediately useless. We won’t actually be using universal identity in this demo because all of our infrastructure will be in AWS and so relies on IAM auth. However, if you’re one of many companies that have infrastructure outside of the major cloud providers, this is for you.

Summary

This gives four kinds of authentication that give broad coverage for our infrastructure. If a service or program is being run by cloud-hosted infrastructure, a person, a pipeline runner, or any other semi-permanent infrastructure we control, it can login to Akeyless without needing any permanent access credentials. From there, it can gain access to external systems using temporary credentials, allowing us to build a fully credential-less application.