Chapter 8: Managing Access with Advanced Server Access

Okta's Advanced Server Access (ASA) is a fairly new product, launched in 2019. With ASA, you can extend Okta's core products to your server fleet. With Universal Directory, you get a single source of truth for your server accounts. With Lifecycle Management, you can automate the provisioning of these accounts. With Single Sign-On, you can create simple and reliable authentication for your workflows. Lastly, you can fully utilize the contextual Multi-Factor Authentication (MFA) controls for your server accounts. In this chapter, we will go through why a product such as ASA is needed, as well as what you need to do to set up and manage ASA.

To understand this fully, in this chapter we'll look at the following:

• ASA – a high-level overview
• Setting up ASA
• Managing your ASA environment
• Automation

ASA – a high-level overview

Throughout the book, we have only spoken about managing applications. With ASA, Okta expands their touch plane by securing access to the server infrastructure. By doing so, the road to zero trust becomes a reality for more parts of your business than just users, applications, and devices. Also, as cloud adoption becomes an increasingly important DevOps job, making sure automation is the driver of it all is where Okta fits in.

Managing servers in your organization as part of your own infrastructure, or as part of your business model, means that your developers need to have access. This access is normally given using privileged accounts, either using the Command-Line Interface (CLI) with Secure Shell (SSH) or with privileged accounts accessing the server with Remote Desktop Protocol (RDP). These accounts are granted access based on the role of the accessing user, but over-privileged access can quickly become a problem. Commonly, you will see that...

Setting up ASA

There are a few different steps needed to start using ASA:

1. Install ASA in Okta.
2. Enroll servers and install the agent.
3. Connect your team's servers.
4. Configure your servers.

Let's go through them in order, starting with installing ASA.

Installing ASA

ASA is its own product, and to be able to use it in your organization, you need to purchase it separately.

To start using ASA, you need to install the product in your Okta tenant. The product is available as an application, so you will start as you would when adding any application:

1. Go to Applications | Applications.
2. Click the button for Add Application.
3. Search for Okta Advanced Server Access, click on it, and then click Add.

In the following general setup, you get to fill in an Application Label and Application Visibility:

Figure 8.1 – General settings of the Okta ASA application

By clicking Done, you finalize the installation...

Managing your ASA environment

There are many different things within ASA that you can manage. Similar to what we mentioned earlier, you can also manage groups, users, and so on in ASA. So, we will not go into that again here. Instead, we will look at how you manage projects, which is an ASA-specific feature.

Managing projects

As you might remember, we created a project in the preceding section, to be able to create the enrollment token. If you want to secure anything in ASA, you will need a token. The project is used to connect a set of resources with a set of configurations. You can compare it to a domain in AD. The project will let you manage different kinds of servers or web applications. So, after you have created your project, as you did to create the enrollment token for a server, you want to add groups to it. Before we can do that, we have to create the group. When you have integrated ASA with Okta using System for Cross-Domain Identity Management (SCIM), you can sync...

Automation

Automating the enrollment of servers in ASA is eventually the best way to scale your infrastructure. This allows the quick management of all the servers across the board, along with the needed access per group and user. To make this happen, your infrastructure automation tools require a solution to allow your identity management to scale along with the infrastructure.

Using tools such as Hashicorp's Terraform (https://www.terraform.io) gives your admins options to create baked-in solutions that are run as soon as new servers are spun up. This allows enrollment automation to happen based on the common usage and access grants that are needed for those servers.

Important note

Okta also has a certified Terraform provider. To understand more and implement it, please visit https://registry.terraform.io/providers/oktadeveloper/okta/latest/docs.

Perhaps you have a service that requires its own server for each customer. Customers can sign up for free and you need...

Summary

ASA is a great way to extend your identity-centric management to your servers and infrastructure. It allows your DevOps engineers to be busy with what they need to do without securing, updating, and managing static keys and credentials. This chapter gave insight into usage, but also showed steps on how to set up, install, and enroll servers. We also discussed how users can install their client to access their provisioned servers. We explained how project management can be done within ASA and we lightly touched on adding ASA as part of infrastructure automation using tools such as Hashicorp's Terraform.

In the last chapter, we will talk about the last product in Okta's IT products range: Okta Access Gateway (OAG). With OAG, you can modernize your on-premises application landscape by incorporating them into your Okta setup and start shrinking your legacy web access management systems.