The Right Way to Use AWS CodeStar
TL;DR
AWS CodeStar is a useful service for those wanting to quickly get a project started with a CI/CD workflow using AWS services. In my opinion, the less experienced AWS developer should only use it for personal learning, not for production code. The service abstracts away too many important AWS concepts that will ultimately hinder the new AWS developer who wants to become proficient in the AWS-way of doing things. So, it’s best to use CodeStar as a blueprint of how AWS expects you to build applications on their platform, but then mimic it in your own applications instead of building off of it.
What is AWS CodeStar?
CodeStar is an AWS service, initially released in 2017, that lets you “quickly develop, build, and deploy applications on AWS.” For the frequent user of AWS, we get excited anytime we see “quickly” associated with something since we’ve all been stuck in one AWS console or another for far too long trying to figure out why our configurations aren’t working. In that respect, this service truly delivers on its promise.
Your CodeStar project starts by you selecting from one of the templates AWS has for you.
After selecting a template, in a matter of minutes, CodeStar:
- provides you a boilerplate source code
- builds a CodePipeline connecting your repository to a newly created S3 bucket
- creates a CodeBuild project to compile that source code and place it in another newly created S3 bucket
- provides a buildspec.yml file for you to configure the previously mentioned CodeBuild process
- creates your CloudFormation stack with Lambdas, virtual servers on EC2s, or an ElasticBeanstalk environment (depending on which template you selected)
- configures CloudWatch logs and streams for your resources
- sets up the IAM permissions for all the services mentioned above
That last bullet point alone would make any AWS developer love this service.
If you read that list and know you’ve configured all those resources and built several AWS applications, then CodeStar may save you a lot of time from repeating yourself. If, however, you haven’t personally set up a CI/CD workflow with CodePipeline and CodeBuild, haven’t written a buildspec.yml file, haven’t set up an ElasticBeanstalk or a SAM template.yml to work with CloudFromation, and still aren’t confident with IAM permissions, then CodeStar is a great resource to show you how those services should be setup.
Model It, But Don’t Build Off Of It
The reason I suggest using CodeStar purely as a teaching tool is because in order to learn the AWS-way of development you need experience with their central concepts and services. If you’re not experienced with setting these services up, then once troubleshooting errors starts you’ll find yourself at a significant disadvantage.
The benefit of the service is all the initial configuration it provides for you, but that abstraction also reduces your learning opportunities. Lastly, CodeStar makes some assumptions for you which results in a setup that may not fit your needs.
Missed Learning Opportunities
In AWS’ flagship documentation white-paper, AWS Well-Architected Framework, it discusses key AWS services and lists CloudFormation singularly as “essential to Operational Excellence.” Clearly, CloudFormation holds a prominent position in the host of AWS services, so an AWS developer should definitely be very familiar with it. Since CodeStar handles a lot of dealing with CloudFormation behind the scenes, it limits the depth of learning the developer will experience. That’s one reason why you should use CodeStar to see how AWS sets up CloudFormation, but then build your own by modeling their approach.
Similarly, CodeStar performs a lot of IAM role and policy creations for you. The AWS Well-Architected Framework states that IAM is a key part of an information security program and that it’s “privilege-management elements form the core of authentication and authorization” in AWS. IAM is obviously an important services in AWS, and CodeStar helps by removing the user’s need to configure these permissions and quickly develop, build, and deploy. Again, though, the drawback for the inexperienced AWS developer is lost opportunities to get your hands dirty and learn through experience.
Issues with CodeStar
“Luke, this all sounds great, so why do you say to only use it as a blueprint instead of building off from it?”
While it’s nice that CodeStar jump starts your development and deployment, it’s also important to realize that the service provides generic templates which means that what you’re given may not actually be what you need. This is where I find flaws with use CodeStar for production.
For instance, CodeStar provides so much boilerplate that it is creating resources you may not need. When I selected the Node.js serverless template, it automatically created CodeDeploy deployment groups, Lambda versions, and permissions for each of the Lambdas. Those all count as Resources, and since CloudFormation has a strict 200 resource limit, it only takes about 40 lambdas to reach that limit if you keep the bulky overhead CodeStar decide to give you.
Another issue is that CodeStar violates the principle of least privilege. One of AWS’ central tenants is the principle of least privilege when creating IAM policies and assigning those policies to roles or users. According to their IAM documentation, when developers are giving an entity permissions, it’s considered best practice to “start with a minimum set of permissions and grant additional permissions as necessary.” This is a more secure approach than giving all users and roles access to all services and resources. Yet, AWS violates this principle when CodeStar creates your IAM permissions.
When I set up a CodeStar project using the Node.js serverless template, I found a ToolChain role created for CodeBuild. That role was given full access to eight services including CodeCommit (which I didn’t select), CodeDeploy (which I don’t want), and ElasticBeanstalk (which I don’t need since I chose serverless).
So, not only am I being given resources and access to services I don’t need, but I’m given full access to them. If your modeling IAM best practice after the CodeStar, then be aware that getting trigger happy on granting full access to all kinds of services is not the approach to take.
My last point is regarding Permissions Boundaries, which CodeStar automatically makes for your IAM roles. A Permissions Boundary is a more advanced feature in the IAM management, and what it does is set the maximum permissions that a policy can grant an entity. You might be asking yourself, “but wait, don’t IAM policies set what maximum permissions an entity has?” And, you’d be right. But, this sets a maximum on what permissions you can offer an entity; hence, permissions boundary. So, if IAM roles specify what an entity has permission to, then permission boundaries specify what permission policies can be given to an entity in the first place.
That might seem like an odd extra step, but it’s meant to help development teams. A team lead might want to set permission limitations on certain teams or services, so that developers cannot exceed them. Hence, Permission Boundaries.
The problem though is that CodeStar fails at the principle of least privilege, again, and provides boundaries to a host of services you may not even use. Also, if you’re a small team or solo developer, Permission Boundaries aren’t all that helpful, but CodeStar gives them to you anyways. It can lead to extra headaches when you’re troubleshooting your stack since Permission Boundaries are not often one of the first go-to place to fix an issue.
Using CodeStar the Right Way
With all that being said, there is great learning to be had by modeling AWS’ devops from CodeStar. In its defense, since CodeStar doesn’t know what application a user is building, the templates have to be generic and widespread (hence the full access IAM permissions and additional resources). I have built a production application from a CodeStar project, and quickly felt constricted because of their way of configuring a stack. I was able to learn a whole lot when I realized I didn’t want to be building off of CodeStar and started reverse engineering a lot of the useful services they did set up for me.
So, I suggest starting off by making a CodeStar project, and then try to rebuild it on your own. Read through the services and source code created to see how AWS builds a project with the stack you requested. To learn about a good CI/CD workflow, try to mimic their CodePipeline stages. Set up a CodeBuild project with the same environment as CodeStar, and rewrite the buildspec.yml file found in the source code you downloaded. Then try to update your source code and see if your newly created CodePipeline behaves just as CodeStar’s did. After that, depending on which CodeStar template you chose, dive into those IAM roles, the services’ configurations, and start building them out yourself.
There’s plenty of learning to be done here, and you’ll quickly find out how many resources CodeStar made for you. It really is impressive. In the end, try to recreate everything CodeStar handed you. Doing this will be your best teacher in walking you through the AWS-way of development, and will allow you to build an AWS application without all the overhead that comes with a CodeStar project.
