DEV Community

Ricardo Sueiras for AWS

Posted on • Updated on • Originally published at blog.beachgeek.co.uk

Automating AWS SSO and G-Suite synchronisation with SSO Sync

update-July 28th

The ssosync tool has had a lot of interest and the community has updated the tool. This means that you should refer to the project home page https://github.com/awslabs/ssosync and check out the README.md for what changes you might need to make to get this tool working.

Next level ssosync

In a previous post, I talked about setting up AWS Single Sign On (AWS SSO) with G-Suite, and then using an open source project called ssosync to syncronise users and groups from G-Suite into AWS SSO. You can take a look at that post here.

In this post, I want to look at some recent work that Lee Packham has done to make running that sync job super easy to do. We will automate the running of ssosync using a schedule AWS Lambda function, and we will set that up using infrastructure as code (IaC) using AWS CDK.

When you finish this walk through, you will have setup ssosync to run on a schedule you define, with logging sent to AWS CloudWatch.

What you need before you begin.

NOTE: Using Lambda may incur costs in your AWS account. Please make sure you have checked the pricing for AWS Lambda and CloudWatch before continuing.

[1] You need to have followed the steps in the first blog, which means you will have a number of important configuration files: credentials.json, token.json and aws.toml files that you used for the configuration of ssosync.

[2] You also need the right binary file for ssosync. If like myself, you originally ran this on your local machine, you might be using a different binary to what is needed when running on AWS Lambda. As per the GitHub README.md, you require the AMD64 binary for AWS Lambda. Thia can be downloaded from the Releases page - (ssosync_Linux_x86_64), but the README.md file provides alternate options.

[3] You will need to install AWS CDK before you can begin.

This will not take you long, but it will require that you have a NodeJS environment. You might want to consider using AWS Cloud9 as a good way of running this if you do not have this immediately available.

Once you have these to hand and setup, you can begin.

Clone the repository

You will need to clone the project repository. From your working directory, you can

$ git clone https://github.com/awslabs/ssosync.git

Enter fullscreen mode Exit fullscreen mode

Which will clone the project and this should leave you with a file structure that looks a little like this (remember, those others files were created as part of the initial setup, and the first blog post)

Structure

Setup the environment variables

The next step is to set some environment variables. I am running this on my Mac so this is how I would set these, (if you are using Windows/Powershell, follow the README.md)

Note! When setting the environment variables, you may need to adjust the path to where your files are. These settings work for my layout, but they may need to be adjusted for yours.

I copied the environment variables and the ssosync binary to the ssosync folder before running the installation, and I ended up with the following file structure. This might be helpful if you run into errors when running the cdk deploy command.

deployment structure

With that structure setup, I set the environment variables as follows:

AWS_TOML=../../aws.toml
GOOGLE_CREDENTIALS=../../credentials.json
GOOGLE_TOKEN=../../token.json
SSOSYNC_PATH=../../dist/ssosync_linux_amd64
Enter fullscreen mode Exit fullscreen mode

Deploy via CDK

Once the variables have been set, all you now need to do to deploy the function into AWS Lambda is run 'cdk deploy'. Make sure you are in the right folder and then run the command.

$ cd deploymnets/cdk
$ cdk deploy
Enter fullscreen mode Exit fullscreen mode

Note! If when you run 'cdk deploy' you get errors, like this one, you may need to do an npm update and then re-run
npx: installed 8 in 2.443s Cannot find module 'typescript'
Require stack:

  • /Users/ricsue/.npm/_npx/61409/lib/node_modules/ts-node/dist/index.js
  • /Users/ricsue/.npm/_npx/61409/lib/node_modules/ts-node/dist/bin.js Subprocess exited with error 1

You should see the following screen if all is ok, so press Y to kick off the deployment

start of install

If all is successful, you should see output like the following:

success install

If you get an error, then check the next section before trying again.

Bootstrap error

When you run the cdk deploy command, you may get the following error:

error

To resolve this, from the command line enter

$ cdk bootstrap aws://{yourawsaccount}/{aws-region}
Enter fullscreen mode Exit fullscreen mode

And you should get the following output. Once completed, re-run the cdk deploy command.

bootstrap

Post deployment

Once the deployment has been successful we can have a look at what has been deployed.

If we check out AWS Secrets Manager, we can see that the configuration files that we needed to ensure were kept safe are now being managed by AWS Secrets Manager - one less thing for us to worry about how we manage and keep secure.

secrets manager

We can see the AWS Lambda application list and we will see our application, SsoSyncStack

AWS SAR

From here we can check how the function is running by checking out the monitoring tab and then diving down into the AWS CloudWatch logs.

Monitoring

So, this all looks great, now let us test it out.

Testing and checking the logs

When this is deployed, the default schedule is set to 1 hour. You can change that if you want by going into the AWS CloudWatch events and editing the schedule.

When the function is triggered, it will output to a CloudWatch log group as you can see from this screenshot.

logs

When you open the logs you should see output that looks like the following:

logs

And you should be able to see the completion of the ssosync process (and also captures the Lambda metrics from a billing perspective as well)

completion

Now I am going to add a new user to G-Suite. I add Jay Dee Salinger

add user

and in a few minutes we see the following:

new user added

And finally, when we look in AWS SSO, we can now see the new user and then go on to assign them AWS resources.

finish

Conclusion

The ssosync project has provided some additional options on how to run and keep your G-Suite and AWS SSO user and groups in sync.

Using AWS Lambda, AWS CloudWatch events and AWS Secrets Manager allows you to automate this task and ensure that you keep the configuration files safely managed.

Check out the ssosync project, the GitHub repository can be found at https://github.com/awslabs/ssosync

Top comments (4)

Collapse
 
grenguar profile image
Igor Soroka

Thanks for the great article! Unfortunately, now there is no CDK option in the deployments of ssosync.
However, I found the commit where it is still available.
In CLI:
git branch cdk-deployment a1860e71d3477ffded5e15b172ca6c32e4384811
git checkout cdk-deployment

Collapse
 
094459 profile image
Ricardo Sueiras

Thanks for this, I need to set some time aside and update this.

Collapse
 
grenguar profile image
Igor Soroka

Great!
One more question:
what will be the best way to automate the process of assigning the permission set for the account. Also assigning a group to the account. Any cloudformation or cdk advice?

Thread Thread
 
094459 profile image
Ricardo Sueiras

Good question, and I know what you mean. I did not look very hard at how to automate that, but I seem to recall reading something about this. Again, something else I need to look at ;-)