In the second of our Caylent API Tutorials, we discuss how you can set up and auto-add SSH users to your stacks and infrastructure using Caylent. This tutorial covers the 5 necessary steps for optimizing team management using Postman and is supported by a video tutorial on YouTube (also see below). You can create teams, invite users and configure the user settings to include a user. It is also possible to define if they are admin or just have basic SSH access minus the sudo commands.
For this tutorial, you’re going to need:
- An active Caylent account with AWS cloud credentials associated. To sign up to Caylent, click here. For details on adding AWS credentials, click here.
- A configured Postman account. If you haven’t already set Postman up, then check out my first tutorial.
- A GitHub account and a published public SSH key. Follow the GitHub guide here to complete this process.
- Access to your AWS account to change firewall rules.
- Caylent API Docs:
Step 1: Setup User Account
So, let’s jump in. With the Caylent API collection downloaded, login to Postman. Our first task is to set up your actual user account under account settings (See image (i)).
The two details we concerned with here are the github_username and the ssh_username (See image (ii)).
Inputting the ssh_username is optional. If specified, this becomes the default ssh_username. If this username clashes with another on the stack, our system uses the github_username instead.
On top of providing a backup username, github_username simply queries your GitHub account for any published public keys associated with it. These keys are used to authorize each individual.
Note: You can use the “GET User Details” function here to pull and check this information quickly if you’re already on the system. Click “GET User Details” and Send to perform this command. The “PATCH” command will allow you to update this info if necessary.
Within GitHub account settings, you can access and query your public key. It is then a straightforward process to add those to the authorized login key.
Step 2: Create a Stack
Our next step is to utilize the API How To Guides to create a stack. To do this, follow the steps for the “Caylent API – Env” collection.
Choose the “Stacks” folder and “POST Create Docker Stack” to launch a default Caylent stack. The default stack created will be called “docker-today-1” within the “us-east-1” region. At this point, if you click “GET 3. List Stack SSH Users” and Send, you should see your own details listed including the ssh_username and GitHub keys.
As the stack creator, you will automatically add users with full admin rights.
Step 3: Team Management: How to Add a Team Member
For this action, move to the API How To Guide “Create a Team and Invite a User.”
Click “POST 2. Create Team” and enter your team’s identification in the (“name”:) command before clicking Send.
Use the “POST 3. Invite User” function to send a team invitation to a new user’s email address. Once users accept the invitation, they can be added as an SSH EC2 user.
Step 4: Adding SSH Users to Stack
Note: Users who have yet to accept a “pending_invite” cannot yet be added as SSH users. Full team members who are already available can though.
Click “POST 4: Add SSH Users to Stack” and enter in the team member’s email. To grant admin access set (“admin”: true)—change to (“admin”: false) to revoke admin settings.
Step 5: Launch Stack
With the team now setup and team members invited/created, it is now possible to launch your first stack.
Move back to “Caylent-API Env” documentation for this part of the tutorial.
Click “POST Launch Stack” command and click Send.
Allow five to ten minutes for the stack to finish deploying.
Your Caylent account dashboard will now display your fully deployed stack. From there move to the Resources tab for more information on the full list of “Resources Linked to this Stack”—including the IP addresses and DNS for your Load Balancers.
The Stack Properties tab will also give you a list of users who now have SSH EC2 access granted to the deployed stack.
Step 6: SSH EC2 Access: Your AWS Account
Let’s jump over to AWS and see what the stack looks like there. Firstly, from within the CloudFormation section, we can see:
- Network: This is a collection of all of your VPCs and subnets that stacks use
- Stack: The CloudFormation template for stack resources
Click on the Stack template to see detailed information on all the resources (i.e. EC2 instances, load balancers, security groups, etc.) that actually make up your stack.
Moving to EC2.
Caylent’s default stack composition consists of a 5-instance cluster. Within that cluster, there are 3 master nodes and 2 workers.
Within EC2, click “Running Instances.” This will display all the information on our cluster. Scroll to the right-hand side to see the two different types of ‘Security Groups’ that your worker and manager nodes fall into. Click on an instance to see a more in-depth view of the two Security Group breakdowns of swarm-workers-group, swarm-master-group as well as the EFS Security group.
For SSH access, click swarm-master-group, followed by the “Inbound” tab and “Edit.”
Now “Add Rule,” choose “SSH” from the drop-down box and change “Custom” to “My IP” before clicking “Save” to complete the process.
Complete the same steps in swarm-workers-group.
You now have full SSH Ec2 access for all of your servers using your private key and the ssh_username specified earlier.
Here’s the full video tutorial to guide you through SSH EC2 access and Team Management screen by screen:
Watch the next Caylent API YouTube Tutorial now: Deploy a High Availability WordPress using Docker
Read the next Caylent API Blog Tutorial here: Setup an AWS High Availability Docker WordPress Stack
Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and profit from our DevOps-as-a-Service offering too.