ScaleFT provides a more effective way of managing the credentials users need to access infrastructure, but what about automated services that need privileged access to operate?
Along with an emphasis on closer collaboration between teams, modern DevOps practices have introduced more automation throughout the entire software development lifecycle. Various processes for developing, building, testing, packaging, and deploying code are all streamlined via event-driven, automated workflows. When done well through a collaborative effort, teams are able to ship software quicker and more continuously.
The thing about automation, though, is that the process is doing something a person would otherwise do. That may sound glaringly obvious, but remember that with infrastructure, things a person would do often require privileged access to do so. In order to accomplish this, the services and tools being used must be granted the appropriate rights to perform administrative tasks on your infrastructure. By design, you are handing the keys to the kingdom to automation, which means extra care and consideration should be taken to ensure those privileges are not abused nor are they compromised. One famous blunder was the developer who accidentally checked in his AWS credentials to a public GitHub repository.
Common ways to mitigate these risks might be to wrap an extra management layer around your credentials, or implement a rigorous key generation, distribution, and rotation policy. These activities are hard enough to setup and manage with just users alone, but become even more challenging when dealing with services. Most organizations will have a system of record for their employees, contractors, and consultants, but it’s rare that anyone outside of the Operations team really knows all the services in use given the wide range of cloud-based SaaS tools so readily available.
The way our customers use the ScaleFT platform to manage privileged access for users across teams can also be applied to these types of tools via the Service User feature. While the function of granting short-lived credentials for administrative access ends up being the same, there are some subtle nuances in the authentication process that make the experience slightly different. As services won’t exist in your company’s Identity Provider database alongside your users, we model the Service User in the backend, and validate the claim based on configurable metadata. Once authorized, the Service User can act as an administrator on another server through a secure session.
A common pattern where this applies might be having a commit to GitHub trigger an integration test where the resulting build is deployed to application instances within your server fleet or across your cloud provider of choice. We’ll use Jenkins for this example to demonstrate the role of a Service User.
First, we’ll spin up one Ubuntu EC2 instance on AWS to run Jenkins, and another as our webserver. Enroll both servers with ScaleFT in the Project of your choice, and also install the client tools on the Jenkins server along with Jenkins itself. As with all EC2 instances managed by ScaleFT, there is no need for a key pair to connect.
Create a Service User
First, SSH into the Jenkins instance using ScaleFT and get the user id for the Jenkins user (112 in this example). You’ll need that when registering the Service with ScaleFT.
Create a Service User using the ScaleFT Dashboard. Then create an API Key for the Service User. This API Key is used by the ScaleFT platform to issue a bearer token on authentication.
Add the Service User to a Group with admin privileges on the webservers.
Create a Service
With a Service User, you can now create a Service on an enrolled server using the ScaleFT Dashboard. Select the Service User created, and enter the id of the jenkins user on the Jenkins server (112).
Configure the Jenkins server to enable authentication via the Service User as opposed to an enrolled client.
With the Service User configured, the Jenkins build process can now securely ssh directly into the webserver we created with dynamic credentials generated in real-time. In this simple example, we’ll simply write the index file at the root as a “Hello World”. Note that with the ScaleFT client tools running on the Jenkins server with the proxycommand configured, we can simply
ssh webserver to create a new session with a fresh certificate.
Executing this build will run through a fresh authentication and authorization event in ScaleFT, and generate the dynamic credentials needed to perform administrative access. While only a simple “Hello World” example, this pattern is extremely powerful for DevOps engineers building complex pipelines where tools need to communicate with each other.
It’s our goal at ScaleFT to incorporate our unique method of dynamic access management into the workflows our customers are used to, while providing the security assurances required to operate in production. Having credentials that expire after use helps avoid the situation where a key is accidentally left open or associated to a user who is no longer with the company.
Every feature we build further enables our customers to realize their own BeyondCorp architecture, where trust is only given in real-time based on a set of prescribed conditions. To take advantage of this access management feature and more, get started with ScaleFT today, or get in touch at: email@example.com.