Table Of Contents
- Configuring a shared demo environment for SEs
- 1. Create a role for our SEs so they can admin their own database running on a shared RDS DB instance
- 2. Create a DB user with specify permissions that will be assumed when using the role above
- 3. Create an AWS IAM policy that will be assigned to the role where the data service is running
- 4. Create a role for a more privileged DBA user and assign to user
- Running Teleport with advanced configurations
- Teleport cybersecurity blog posts and tech news
Teleport Blog - How Teleport Uses Teleport to Create and Maintain Shared Demo Environments - Feb 9, 2022
How Teleport Uses Teleport to Create and Maintain Shared Demo Environments
Our Solution Engineering (SE) team is full of individuals who have vast real-world experience building and maintaining complex IT access systems with sophisticated audit layers through their work as DevOps engineers. The problems that we have all faced before joining Teleport are the exact problems that our customers face. So when it comes to our demos, we like to show real-world scenarios aligned to customer usage patterns, in environments similar to our customers. That means that we regularly create resources like EC2 instances, RDS databases, Jenkins clusters, and more to show how Teleport combines connectivity, authentication, authorization, and audit into a single platform to improve security and productivity.
Because these demo environments mimic the real production environments of our customers, they cost real money, and as a growing team, we have an incentive to control costs by not provisioning more resources than are necessary. This blog post will describe how the Teleport SE team built a shared demo environment on top of Teleport Enterprise, so that each SE can get access to their own demo resources, while limiting unnecessary resource provisioning to reduce costs. It will also demonstrate the architectural flexibility of Teleport by mimicking customer requirements for multiple distributed Teleport clusters across their global footprint. The use case we will discuss centers on how to consolidate access to database servers and Kubernetes clusters, and how we use just-in-time access requests to approve changes that require provisioning additional resources that will cost money.
Configuring a shared demo environment for SEs
To set up this central demo environment, we need a Teleport cluster that maintains access to a core set of cloud resources like RDS DB instances. These are real resources that we pay for, so we want to control who can provision resources, and we also need to enable easy access for maintenance and patching. If any updates are needed, SEs can use Teleport’s just-in-time access requests functionality to request access to maintain AWS resources and IAM policy/roles. This allows for authorizing administrative changes across team members while providing an audit of what was changed.
To set this up, there are four steps:
- Create a role for our SEs so they can admin their own database running on a common RDS DB instance
- Create a DB user with specific permissions that will be assumed when using the role above
- Create an AWS IAM policy that will be assigned to the role where the data service is running
- Create a role for a more privileged DBA user and assign to user
Let’s dive in.
1. Create a role for our SEs so they can admin their own database running on a shared RDS DB instance
The configuration below shows an access role for a set of databases that are used by each SE. While we want to use a common set of RDS DB instances to control costs, each RDS instance can have multiple databases. These individual databases can be used by SEs to create their own customer demos. Some things to note in this role config:
- The label
demonstration: yesis listed in the Teleport UI.
external.dbnamesvariable is used to automatically populate the particular user’s set of databases.
external.<attribute>comes from the Single Sign On (SSO) provider used to authenticate the user such as Azure AD or KeyCloak. That allows us to use the same role for all the SEs while still only showing them the unique databases they have access to.
2. Create a DB user with specify permissions that will be assumed when using the role above
The Teleport role will only allow the user to connect to their assigned databases. But we still need to specify what the user can do. That’s where a user comes in. To make sure SEs can administer their own databases, we created the
maintaindata user and assigned grants to manage data in each database.
CREATE USER maintaindata;
GRANT rds_iam TO maintaindata;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO maintaindata;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO maintaindata;
3. Create an AWS IAM policy that will be assigned to the role where the data service is running
Now we need to map all this to an IAM policy. The IAM policy below is assigned to the role where the Teleport
db_service is running. It allows an SE to connect to the RDS database with the user created above. Optionally, instead of
* at the end of the resource, you can specify just one specific user if you need to restrict which users should be able to connect.
Example Teleport database service pointing at the PostgreSQL RDS:
- name: "postgresql-db"
description: "🐘 db database"
4. Create a role for a more privileged DBA user and assign to user
As we have mentioned, this level of access allows an SE to use and maintain data in the database, but does not provide DBA-level access. What if we want to add a new table or schema? Or if we need to make changes to the database instance itself? For these changes, the SE can create an access request for the role
maintain-db which maps to the
adminuser user with higher-level permissions. SE team members can approve each other’s access requests through this configuration but are not allowed to approve their own changes, keeping each other accountable. Because Teleport uses short-lived certificates, and not shared credentials like SSH passwords, SEs are limited to two hours to apply their changes to the database before the elevated access expires and they revert to their default role. And of course, all changes to the database are audited through the Teleport Audit Log.
To configure a user that can manage databases and users while connecting through Teleport, first create them via the following in the PostgreSQL database server:
CREATE ROLE adminuser CREATEDB CREATEROLE LOGIN;
GRANT rds_iam to adminuser;
GRANT rds_superuser to adminuser;
The Teleport role below will match to the
adminuser user that SEs can request and then make their changes via Teleport Database Access. Changes are audited so we can easily identify what changes were made.
Running Teleport with advanced configurations
For the purposes of a simple demo, the entire SE team could use a single Teleport cluster that provides unified access to Linux and Windows servers, databases, Kubernetes clusters, and DevOps tools like Jenkins, GitLab, Grafana, and more. However, our customers often want to see Teleport run with configurations that mirror their own production deployments. For instance, they may want to deploy Teleport in AWS directly on an EC2 instance to support RDS access, but in GCP, they may want to run Teleport on a Kubernetes cluster powered by GKE for containerized applications. So we give SEs the ability to deploy their own Teleport instance using things like Kubernetes, docker-compose, CloudFormation. However, just because a customer has two Teleport instances, they do not create islands of access. By using Teleport trusted clusters, this new deployment can still securely access the database resources we talked about before, giving the best of both worlds. SEs can still access the central resources that have been provisioned, while demonstrating that multiple Teleport clusters can be used to unify access to globally distributed resources.
Teleport cybersecurity blog posts and tech news
Every other week we'll send a newsletter with the latest cybersecurity news and Teleport updates.
We have stepped through an example of providing centralized access and auditing for multiple shared demonstration environments. By requiring SEs to request elevated privileges before deploying or configuring new instances, we’re able cut costs while still showing demos that mimic customer environments. Want to try Teleport yourself? Download the Teleport community edition or reach out to us today to see how we can help your team securely access your infrastructure.
Stay up-to-date with the newest Teleport releases by subscribing to our monthly updates.