Staying in theme with previous posts I have worked on, I will continue to look at ways to approach security within the operations management applications. Previously I covered credential management and how external vaults can help with Discovery and Service Mapping. In that area, the credentials were merely a means of access for the ServiceNow platform to find information and never gave access to a ServiceNow user to later directly have native rights. If you have done any work with Orchestration, you may have made remediations where again the platform is doing the action and simply offers up a way for someone to take it without ever having native access to any of the systems. This is a great approach to helping control how many people have the direct ability to login to systems or applications on the network.
In providing support for Amazon Web Services (AWS) in the ServiceNow Cloud Management solution, we are again looking for ways to improve the security of how access is controlled in order to limit the number of users that need native access to AWS. The obvious first approach is to offer catalog items with orchestration to perform any needed tasks on a requestor's behalf, similar to how offering remediation workflows can allow previously defined actions to be taken. Out of the box support for Cloud Formation Templates to be used as catalog items opens up other areas of AWS services to complement the ability to create EC2 instance catalog items. There can be a whole post on just this topic, but for today I wanted to tackle the case where sometimes there is no other way to satisfy a customer's needs other than by providing a means to use the AWS console.
Within the Cloud Resource Catalog, there is a pre-built catalog item to directly address this need without the need to manage the creation of Amazon credential for every person who needs access.
By simply requesting this item, the user will be provided with a link that will allow direct access to the native AWS console for a limited window of time. After the request has been completed, by simply going to the My Virtual Assets page and selecting the My Amazon Assets tab, the user will be presented with a link and its expiration date that when selected will automatically log into AWS.
After presenting this capability to some customers, the next set of questions would be on the topic of how to implement some additional granularity on the level of access that is granted, as the out of the box catalog item is configured to grant full rights. As I dug into the workings of this catalog item, I felt that a walkthrough of the process would be a great topic for posting up for you. Looking at the catalog item, I found that it was referencing a policy template but I didn't see any modules under the Cloud Management application that addressed admin policy templates. The template can be found by navigating to aws_policy.list.
Viewing the template shows that it is based upon standard AWS conventions that are well documented by Amazon. Reviewing the policy shows that it is granting ("Effect":"Allow") any action to be taken ("Action":"*") to all resources ("Resource":"*").
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
To demonstrate implementing a policy with tighter controls, I chose to make a policy to limit user access to only S3 buckets when the native console is launched. The first step is to create a new entry in the aws_policy table for us to work with. The template follows the pattern of defining whether this is a permit or deny section, what user will be allowed to perform and what the target object(s) will be. In my research, I found that when working with S3 rights, the ListAllMyBuckets action was needed for the others to work, so that is the reason for the first section below. The second section is going to Allow me to take any action of those available to the s3 category. And finally, those actions can be taken on the bucket named test and on any within it.
{
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test",
"arn:aws:s3:::test/*"
]
}
]
}
Now that we have a different set of rights that can be granted to the console, we need a catalog item to use. You can find the current item under Amazon AWS Cloud application, in the Security Token Items module. The catalog item named AWS Console Access can be modified to use a new template or copies can be made if there is a need or multiple admin policy templates to be available. Once the new catalog item is created and available in the Cloud Resource Catalog, order the item and open the link that is provided. The AWS console should launch and provide access to only the areas that the admin template permitted, in the case of the screenshot below, all my S3 buckets.
However, if I attempt to look at EC2 information, access is denied.
Now you can provide access to the native AWS console with a subset of features and on a time limited basis without the need to create user accounts on the Amazon Web Services side. Hope this walkthrough has been useful to you and thank you for reading.
AWS Policy documentation on ServiceNow site
