Easily enable SSO (Single Sign-On) to protect your AWS Accounts

Enabling SSO on your AWS Accounts is strongly encouraged, adds additional security, access to multiple accounts from a single entry point (with different permission sets), and above all, it is free.

The following is a walk-through of how to enable Single Sign On in the AWS console. These instructions are for people with individual accounts to a few accounts. Actually, these instructions are just a good general starting point for smaller size orgs.

Enable Organizations

  • Log into the AWS Console as the Root account
    • Note: This should be in the primary account that will hold the Organization if you have more than one account. These instructions only go through getting SSO enabled, not adding accounts to an Organization.
  • Go to Organizations (once again another service free of charge)
  • Click “Create organization” and then click “Create organization”
    • Note, this can only be done for one account in the org, and it would be best to do this in a new account if you are going to be adding a large number of other accounts or people.
    • If this is your only account it is not a big deal. Just add it to your base account.
  • Verify your email address to finish the setup process.
    • This is a default. I think it is for security reasons to ensure that not just anyone that has admin access to the account creates an Organization.
    • The email will be sent to the root account email address.

Enable Single Sign On

AWS SSO Landing Page
  • There are two options here. Click the link to “Enable AWS Single Sign On” or search for SSO in the top level search bar.
  • Click “Enable AWS SSO”.
    • Assumptions here:
      • You are going to use AWS as the Identity Source.
      • You have already created the Organization
      • You are happy to be getting this done, and looking forward to being able to access all your accounts from a single location. (Without being charged extra for it). (This sounded much funnier when I was writing it the first time)
Default Landing Page for SSO After Account Creation

Configure Single Sign On

  • Go to Settings.
    • Identity Source — Leave this set to AWS SSO.
      • For me this makes sense. I don’t have a third party solution for this, and I don’t want to have to manage it.
    • User Portal — you can create a custom url. This is nice so that you do not have to attempt to remember the default one that is provided.
    • Multi-factor Authentication — these are my preferred settings.
      • Prompt for MFA – Every time they sign in (always-on)
      • MFA types – for me, either works, but I like to use Authy, because then I can get into it from anywhere. And, if my device breaks, I still have access to my keys.
      • If a user does not yet have a registered MFA device
        • Require them to provide a one-time password sent by email to sign in
        • If you are going to protect your accounts, go all the way with it.
      • Who can manage MFA devices — Users can add their own.

Create Users and Groups

The Create Group Pop-up
  • Next step is to create Groups and Users
    • I like to add the Group first because then I can just add the Users to all the groups when I create them.
    • Users are the people that will have access to the accounts.
    • The groups are just groups of users. The permissions are not tied to there.

Configuring Account Access

Setting up and configuring AWS Single Sign On is almost complete. The last remaining steps are to create Permission Sets and then to assign them to users or groups that are bound to accounts. As a default, I like to create an Admin and ReadOnly permission set. You can attach the users/groups to the accounts first, but I prefer to create them the other way and to create the permission sets, and then attach users/groups to the accounts.

  • Create Permission Set
    • Standard that you can select from a list. These are limited to an hour.
    • Custom. Can still be almost the same, but, one nice thing is that you can change the timeout to up to 12 hours.
Dialog for adding permission set
  • Assign users and groups from the AWS Organization Tab.
    • I only have the 1 account. Click the check box and then click “Assign Users” (it should really read assign users and groups)
    • I like to assign groups and not users. So I have added both to my mix here.
    • Note, you can only add 1 group at a time or they get all the permission sets.
  • On the AWS accounts page. Click on the Name of the account to get an overview of it.

You can now login via SSO

All you have to do now is go to the link that is provided in the configuration. Once you log in, you will get a list of the accounts that you have available to you and the roles that you can assume in each one.

That is really all there is too it. It is quick and easy to setup, and after you start using it, you will wonder why you did not do it sooner. This is a great solution for solo developers, small companies, and even larger companies if you want to get into integration with your own federation servers.

Setting up the cfnmason project for Python

Cfnmason is yet another tool that can be used to manipulate cloudformation stacks. It is not designed to be a replacement for CloudFormation like Terraform, but as a means of making building and managing them easier. I had written a version of this ages ago in Ruby, but with most of my work now being in Python, I am creating a new version in Python. As I have never created an exportable Python package, this will track the process of building and releasing a new PyPi package.

Oh, and to keep things interesting, I am doing this on a mix of Windows 10 and Linux.

Creating the default layout using Poetry

The first thing that we need to do is to create the base package. I could do it by hand, but I want to try out the Poetry package and see if I will hate the decision later.

c:\dev> poetry new cfnmason
...
c:\dev\cfnmason> tree \f \a

|   pyproject.toml
|   README.rst
|
+---cfnmason
|       __init__.py
|
\---tests
        test_cfnmason.py
        __init__.py

Init a new Git repo and add a .gitignore file

These are more civilized times. As such, I almost always create a git repository when I am working on a project, even small ones. They may or may not be public, and it can fluctuate on which platform I use to host my code. This time I am opting for Github, and have uploaded the code.

I have been using gitignore.io to generate base .gitignore files for ages. Type in a few operating systems, the language you are coding for, any IDEs, etc, and you can have a useful .gitignore file right out of the gate. Sure you can do it by hand, but this is quick and easy, and it can always be edited later.

Modifying the Readme file

Poetry starts you with a README.rst file. I don’t know about you, but I have been working with MarkDown for ages. It is common on a number of platforms and there is support for it in a number of editors. I understand the RST files are really designed for technical documentation, but I can burn that bridge later. For now, I need a decent starting point.

We could have started by writing out the template by hand. This would have been long and tedious. Instead, I am using a template. By using a template, I am up and running quickly. I can add and remove parts that I do or do not need, and hopefully, I will not forget a major part. As this is the first pass, I am not going to update the entire thing, but at least get the project name in and the fact that I am working on it.

The license file

The last thing needed before I start working on the code is the license file. Which license you choose is up to you. Personally, I like to use the MIT license. It lets people do what they want. As this is an opensource project, I feel that people should be able to use it as much or as little as they want.

The easiest way to do this is using the Github console. Just add a new file via the web interface and name it LICENSE or LICENSE.md in all caps. Then you will have the option to choose from a list of known licenses.

That is it and next steps

Hmmm. This took longer to write than the work to get the base package up and running. And, that is going to be expected. But, it should also show some of the thoughts and considerations that are needed when creating a new project. Especially if it is going to open for the world.

With that I will leave you to it. In the next couple of days, I am going to start adding in the libraries that are needed to begin working on the project. As I have written this in Ruby before, I have a rough layout in my head of how I want the application to work. And, I know what libraries are needed to meet the core functionality.

The question that I have for myself is if I should take the time to ensure that I update the design docs. Having a design doc is a great way to ensure that you are not missing any features. I am going to have to sleep on it.

Writing Tech Blogs are Hard Work

I once read an article that said more people need to write technical blogs. That the problem with much of the technology field was that people did not write in-depth articles on the stuff that they are doing. And, if more people were able to take the time and post a blog entry here and there we would all be better for it. As nice as that sounds, I have to say that writing technical posts are difficult, time consuming, and can quickly go out of date.

First off, writing in general is not easy, and that is before you get to adding the technical part on top of it. There are a number of brilliant developers, system engineers, and devops people that can create some of the most complex and unique solutions to problems, and yet cannot begin to write the first bit of documentation or narratives to describe what it is that they have done. It is not that they are dumb, they just have not honed the writing skill, or just might not be proficient at it. Writing is like coding, if you don’t use it, you can lose it. Also, it is a skill that can be developed and honed overtime. Myself, my writing skills are rusty after taking a long time off from it, and I am trying to get back into the flow.

There are some people that recommend to become talented at writing, you need to be able to dedicate an hour a day to it, or 5 hours a week. And that is just the writing part. That does not tie in working on the technical elements that are needed to provide content for the audience you are trying to reach. Maybe a few years back when I did not have family obligations this would have been possible, but now I have to sneak in time here and there. And, for the casual tech blogger, this is not going to be the case. Unless you are doing a lot of writing for work, there is little time to develop your writing skills. This leads many people to turn away from writing a technical article even though they might have some of the best ideas, if only they could get them into a usable format.

Now, the next big item on why it is so hard to write technical articles is that gathering together the technical information is not easy. Don’t get me wrong, that is not to say that there are not a number of topic that you can write on. That is far from the truth. There are probably thousands of areas and topics that can be written about. But, just like writing, it takes time to gather that information. Now, there are a few high profile bloggers that are able to dedicate their jobs to writing technical blogs. Many of them are evangelist or full time employees whose job it is to talk about certain technical areas. That is great for them, and to honest, I am a bit envious. For the average person devops engineer or develop it is not so easy.

There are some companies that will allow you to blog on the work you are doing, but for most people that is not the case. So, on top of your full time job, you then most go and use your own resources and your own time to work on getting together the data, the code, and whatever else, to get together the technical information just to begin writing the article. Once the work has been done to vet the project or the topic that you are looking at writing about, you have to circle back around and figure out how it is that you want to get the information together to put it in a story for others to read. This goes back to item number one, and I have already mentioned how difficult even that first step is. Now we are taking it to a higher level by saying you do not just have to write a story, but that you must structure it around the technical information. 

So, after getting the data together and know what you are going to write about, you have to structure it. There are screen shots that have to be made, code snippets that must be shared, links to technical information that must be included. As easy as all of that sounds, it is much harder than it sounds. Figuring out how to clip an image or not make it be 4 megs in size, or how to get the images aligned so that it all looks correct. Then there is the question of where do you put your code you are going to share. How do you get the numbers showing on code? How do you enable syntax highlighting on the code samples? All of that is not easy. All of that can be overwhelming when you just want to write an article to share some information with other techies.

And the last fact of the matter is that you never know if all your efforts are for naught. You could write a great article, but if people don’t find out about it, then what do you do? Do you keep plugging away and hope people will stumble upon the articles you have written? Nobody wants to do a bunch of work for nothing. So, in recap, writing technical articles is difficult. It can be hard, and it is not always rewarding. I thank all the people that stick with it, but I understand all of those who don’t.

DevOps Consultant vs DevOps Engineer

What is the difference between a DevOps Consultant and a DevOps Engineer? This question recently came up and I wanted to add my thoughts on the topic.

First, lets address the fact that consultants are almost always hired to work on a specific project or to address a specific issue the company is facing. As such, the role of a consultant will probably always be different than that of a regular employee. The regular employee has to deal with the mundane job of ensuring the lights are on, email, ongoing projects, operations, regular development tasks. The list goes on.

In a lot of ways, consultants are free from this type of scenario, and can focus on the one task or 5 tasks at hand. As such, sometimes consultants can get more done than a regular employee that has other responsibilities. Also, and because they are seen as experts in their areas, sometimes, the views of consultants are more highly valued or taken to heart by upper management.

With that out of the way. There is a difference. The article does stress the teaching, part. I am not sure that it really stresses the transformation part as much. A devops consultant, if they are good, will pair up with people at the company and help teach how devops works, and how to successfully transform a company and a group. They are brought in to look at a situation with fresh eyes, and potentially help shift the entire way that a group is doing things.

This does not mean that there is really a difference in skill sets between a devops engineer and a consultant. But if there is one, I would say it is around teaching and the ability to focus. There is also the other part, and that is the business acumen that consultants learn because they tend to have to deal with people from all levels of the company.

On the other hand, consultants, unless they are on a long assignment, may find that while they are making high level changes, do not always have the chance to get their hands dirty. This depends on the company they are working with, and what the job entails. So, a devops engineer, can end up having more time developing solution, whether it be configuring CICD, infrastructure as code, automating application deployments, automating error responses. Because of this, consultants sometimes have to dive deep on side projects to ensure that their skills are staying up to date with what is currently going on. Tongue in cheek, but sometimes it is just the opposite, and they are scrambling to learn the tool that the customer is using so they can help with that project.

The other reason people bring in consultants is because there could be a skills gap. Company A, realized that they are not moving fast enough and need to change. They go to the IT guys and that group says, “Not my job.” In that case, they bring in consultants because it is quicker to hire consultants than it is to hire full time people. And, unless you are just going to run your company with consultants, you should be bringing on full time people to learn from them or to be filling those roles as the consultants leave.

A bit long winded, but I hope it helps. Ping me if you have any other questions. I have been on both sides of the fence.

Oh. and travel. Consultants normally have to travel.

DevOps is more than just about developers

There. It has been said. Take a moment, and think about it.

There is a push in the community to talk about Continuous Integration / Continuous Deployment (CI/CD), and tying this all to the DevOps movement. About what practices are used to get code to market the fastest, and with minimal amount of code defects. And, I will admit, that I agree wholeheartedly, that CI/CD or some sort of pipeline is important to allow software development teams to move fast and innovate. Or, to just roll out code without doing it every 6 months. I would almost argue that CI/CD is more akin to Agile and Scrum methodologies than it is to DevOps.

When it comes to DevOps, there is a side to this equation that is not commonly being addressed, Infrastructure and Operations.

Infrastructure Ops

InfraOps, whatever you want to call it. This is the glue that holds together all the services that applications run on top of. It is the items that people take for granted when it works, but cry foul when things go down. When servers go down at 2 a.m. InfraOps is what keeps the lights on.

It is easy to dismiss this side of the DevOps house. But, lets quickly discuss all the items that we need to cover here.

Infrastructure Operations List

  • System Deployment
    • Operating systems
    • Patching
  • Virtualization (Docker, AWS, Azure)
  • CMDB
  • Monitoring
  • Software Deployment
    • 3rd Part
    • In house
  • Load Balancers
  • Hardware Failover
  • Disaster Recovery
  • Caching Servers
  • Database Systems
  • Development Environments
  • Backups

This is by no means an exhaustive list of all the items that must be handled for a solution to be properly deployed and supported. But, the idea is to bring to light the side of the DevOps world that is often overlooked. It does not matter how good your code is if you don’t have an infrastructure that will stay online and support your applications. Often this is an overlooked and under staffed area that needs more attention.

Automation is king

The only way to ensure that the Infrastructure is able to support ongoing systems, deployments, and updates is with automation. Every time that a machine is built by hand, a configuration file is manually changed, or updates are performed manually, you have introduced risk into your environment. Each of these interactions is potentially a slow down in the pipeline, or worse, a manual change that has never been documented.

There are a number of tools and processes wrapped around handling Infrastructure Automation: Chef, Ansible, cfEgine, Salt. The list goes on. In some places there people have rolled their own. It does not matter as much about the tool, as long as we are moving away from manual intervention to a more dynamic scalable infrastructure. These tools all require an in-depth knowledge of underlying systems as well as the ability to code. But the end goal is DevOps on the infrastructure as well as on the Development side of the house.

There are places where tools are lacking to help support of automation. While new SaaS Solutions are filling some of these gaps, if you need to run your monitoring system in house, many of the solutions that currently exist are not built around dynamic infrastructure and ephemeral machines. The tools need to catch up with the needs of the users. In the meantime, the back end DevOps guys write workarounds to handle situations like this.

Moving Forward

Moving forward, let us try and look at all aspects of DevOps, from development to application deployment, and from hardware to infrastructure and scaling design. There is still much work to be done, but we are moving in the correct direction.