In this blog, let’s think about the employee onboarding process. Suppose we have 100 new recruits. A sysadmin usually has to do a lot to onboard the employee. One of the onboarding tasks are giving them access to the cloud resources they require. So in Terms of AWS, let’s try to automate it with cloudformation. For a list of given employees, create iam user, create their s3 bucket and allow permission to their buckets. It becomes havoc when employees join and leave the company; i.e creating and destroying resources for them. Lets see how we can do that with cloudformation.

Generally we use the code snippet above to create an s3 bucket named ‘my-unique-bucket-name’.

Also for the Iam user this is how we create. The name for the user is ‘my-iam-user’

CloudFormation For the Bucket Policy Allowing only access to the user

Now since we have 100 employees, thats a lot of work Lets actually make it six. Six or hundred it’s the same with a loop. Let’s understand the foundation of Intrinsic Functions.

ForEach is one of the many intrinsic function in cloudformation. By intrinsic it means they are built in and allows us to perform various operations and transformation on template values of our Infrastructure’s Code. Dynamically generating values and execution time values are major advantages of intrinsic functions. Some examples are ‘Fn::Ref’, ‘Fn::GetAtt’, ‘Fn::Join’, ‘Fn::Sub’, ‘Fn::ImportValue’, ‘Fn::Split’ etc. Combination of these intrinsic functions allow us to deliver significant value with time and cost saving.

The Foreach requires a name so that it can be referred to later using references. ::UniqueLoopName. It also requires an Identifier as a loop sentinel. It is this identifier that is used to reference the individual item at the collection just as foreach in most programming languages. The value contains the collection of objects that has to be looped through. The Output section contains key value pair which is stored in the stack as output.

The identifier or variable is named BucketPolice instead of BucketPolicy because otherwise it would conflict with the name BucketPolicy which already exists and throws an error. Save the file and upload it to AWS S3.

Create a stack and either upload the file or paste the s3 url.

Name the stack and the parameters. We have named the stack as `intrinsic-functions` The parameters contains list of 6 employees.

Accept the agreements and proceed to create the stack according to the yaml file.

Creation of the resources has started

Transformation succeeded by the AWS::LanguageExtensions

More Resource Creation has been initiated by the cloudformation stack.

Some resources have been created and some are in progress. Wait for all resources to be created.

All the IAM users are created. Remember the  UserName: !Sub  ${UserName}-employee-iam-user” ? the ${UserName} is replaced with each identifier from the list of parameters.

All the s3 buckets are created. Remember the  BucketName: !Sub “${BucketName}-employeebucket”? the ${BucketName} is replaced with each identifier from the list of parameters.

Bucket policies only allow the particular bucket to be accessed by the respective user.

All the buckets do have the policy assigned according to the policy Document with the principal as the particular user. No other users have access to the bucket.

And with this the stack creation has been completed.

Now when the employees have to be offboarded, the stack should be deleted. All the users and the associated resources in the cloudformation IAC will be deleted. Whenever new users or resources have to be created, we have to create a changeset with the modified configuration.

Deletion initiated.

We can see no buckets with the suffix ‘-employeebucket’ can be seen in the s3 list after applying the filter

We can see no iam user with the suffix ‘-employee-iam-user’ can be seen in the s3 list after applying the filter.

By this the employee onboarding and offboarding process is automated with a simple list of users.