1
00:00:00,000 --> 00:00:01,520
Hello, everybody.

2
00:00:01,520 --> 00:00:04,540
It's great to be here at Cloud Village.

3
00:00:04,640 --> 00:00:10,740
And in the next 30 minutes or so, we're going to talk about static analysis of infrastructure as code.

4
00:00:11,300 --> 00:00:27,860
Just as a side note, if you're interested in contributing to any of those open source projects around AWS security, IAM security, infrastructure as code, or Google Cloud, feel free to reach out.

5
00:00:27,860 --> 00:00:32,220
It's Barak Shoster at Twitter, or just follow my activity at GitHub.

6
00:00:32,220 --> 00:00:43,280
I really like to work on open source projects, and it is one of the things that is great about BridgeCode that is contributing more and more open source security tooling back to the community.

7
00:00:44,860 --> 00:00:45,900
All right.

8
00:00:45,900 --> 00:00:52,880
So on the agenda today, we're going to talk about the state of open source Terraform modules.

9
00:00:52,880 --> 00:00:55,460
Are they secured or not?

10
00:00:55,620 --> 00:01:03,220
We'll go over how to run Chekhov using two different integrations, pre-commit hook and CI deployment.

11
00:01:04,540 --> 00:01:12,640
And at the end of this talk, you should be able to just download Chekhov and run it on your own manifests.

12
00:01:12,800 --> 00:01:18,160
Before diving into deployment, let's talk about the problem space.

13
00:01:18,160 --> 00:01:29,800
As engineers, like myself, and probably you who are listening, our goal is to move faster and in much agile way.

14
00:01:31,340 --> 00:01:40,380
And when we develop a new product, we need some way to deploy the infrastructure that this product runs on.

15
00:01:40,760 --> 00:02:03,640
Infrastructure as code came to the world to help us just do all this manual work at the cloud providers like the AWS, Azure, GCP consoles of setting up a VM automatically and having this job of setting those instances reproducible, version controlled,

16
00:02:04,160 --> 00:02:06,000
and peer reviewed.

17
00:02:06,000 --> 00:02:13,340
Since for the first time, it's in code, you can peer review it as a pull request or merge request in your VCS.

18
00:02:14,100 --> 00:02:21,060
When you are working fast, you're producing probably more code, and with more code comes more bugs.

19
00:02:21,560 --> 00:02:37,640
So in a lot of times, when you want to just provision a new cloud resource, let's take S3, for example, you might miss some of the default configurations and keep the S3 unencrypted by default or without versioning or without access logs.

20
00:02:37,640 --> 00:02:41,540
And the same goes for other resources like compute resources.

21
00:02:41,640 --> 00:02:48,200
You might forget access keys in your plain text environment variables instead of using a secured store.

22
00:02:48,740 --> 00:02:59,460
And when you're copying pre-made templates from the internet that are unvetted, those issues might repeat more and more.

23
00:02:59,960 --> 00:03:07,640
So Gartner said, and this is often quoted, that 95 of the cloud security issues are related to configurations errors.

24
00:03:08,600 --> 00:03:25,530
And the trend that is being done at the past two or three years, I know that Terraform exists for a little more than seven years, is that we're codifying each and every activity that we're doing in YAML files, HCL files, etc.

25
00:03:28,570 --> 00:03:40,150
These tooling, those manifests that we write, the infrastructure as code, are about provisioning new resources in a reproducible way and about managing them.

26
00:03:40,150 --> 00:03:45,950
But it lacks the security functionality or best practices vetting functionality.

27
00:03:45,950 --> 00:03:48,530
And there are some great tools around this area.

28
00:03:48,530 --> 00:03:57,210
There is OPA, the open policy agent of the CNCF, and also Chekhov, TFSEC, CFNAG.

29
00:03:57,210 --> 00:04:00,910
Each of those is tackling the problem from a different angle.

30
00:04:01,590 --> 00:04:09,630
So let's talk about the problem that we're trying to solve using Chekhov, which is open source and under Apache 2 license.

31
00:04:09,710 --> 00:04:25,850
What we try to understand is the default configuration of any kind of infrastructure as code manifest, meaning Kubernetes, Terraform, CloudFormation, serverless framework, etc.

32
00:04:25,850 --> 00:04:29,410
is secured by default.

33
00:04:29,610 --> 00:04:33,010
So we asked ourselves that question.

34
00:04:33,010 --> 00:04:41,870
Let's scan as first open source modules of those cloud manifests.

35
00:04:42,010 --> 00:04:48,990
So we decided to use Chekhov to scan thousands of open source repositories.

36
00:04:49,770 --> 00:04:58,430
Before diving into the results, there are some interesting stats about the trend of contributing and creating new infrastructure modules.

37
00:04:58,430 --> 00:05:02,110
And this is focused only on Terraform modules.

38
00:05:02,510 --> 00:05:15,450
So back in 2017, 18, and 19, we had a mild growth in the amount of new open source modules contributed around Terraform.

39
00:05:15,670 --> 00:05:29,590
And specifically at the COVID era, around February, probably due to work from home productivity benefits, the contributions of new modules went sky high, which is great.

40
00:05:29,590 --> 00:05:35,810
We'll have open source, more code that someone else is writing, is less code for me to write.

41
00:05:36,070 --> 00:05:45,570
But the thing is, the more code that is being contributed, the more misconfigs that are being found in the open source repositories.

42
00:05:45,570 --> 00:05:52,170
So 48% of those modules have some kind of misconfiguration.

43
00:05:52,170 --> 00:06:01,570
So if we take about 2,500 modules, we'll see a lot of misconfigs there.

44
00:06:01,690 --> 00:06:08,610
And those open source modules, by GitHub statistics, had more than 26 million downloads.

45
00:06:08,890 --> 00:06:14,390
And that's a lot of downloads of misconfigured EC2 instances, S3 buckets, etc.

46
00:06:14,850 --> 00:06:20,490
So just to make things clear, writing code in Terraform does not mean that it's insecure.

47
00:06:20,490 --> 00:06:22,150
It's the other way around.

48
00:06:22,270 --> 00:06:30,570
Terraform gives the ability to peer review the infrastructure's code and to have an impact on the configuration before provisioning.

49
00:06:31,330 --> 00:06:41,750
The thing is, is that this practice of reviewing this infrastructure configuration is still not in place in a lot of organizations.

50
00:06:41,750 --> 00:06:47,610
And what we see is that backup and recovery is very often missed.

51
00:06:47,650 --> 00:06:53,250
Logging and auditing, encryption, Kubernetes configuration, are also missed.

52
00:06:53,250 --> 00:07:04,090
You can understand Kubernetes that has so many knobs and switches, but encryption should really be turned on by default on most of the cloud services.

53
00:07:04,830 --> 00:07:18,510
And if we break it down to the different cloud vendors, we can see that there is a different missing piece on all of those open source modules.

54
00:07:18,510 --> 00:07:31,810
For example, in Google, there is often misconfigured networking piece, while on AWS, Kubernetes is the most often misconfigured code.

55
00:07:32,070 --> 00:07:36,090
So where do those bad configurations come from, usually?

56
00:07:36,090 --> 00:07:47,310
So you can copy them from a blog post, from Terraform registry, from GitHub, from your internal repository where you probably have a platform team creating those manifests.

57
00:07:47,830 --> 00:07:59,610
And it's really not, usually it's not as a result of a bad actor, but merely lack of knowledge or lack of time of all of those best practices.

58
00:07:59,610 --> 00:08:08,950
You have over 160 services only on AWS, and the list of their configurations grows on and on.

59
00:08:08,950 --> 00:08:17,070
So it's really a lot to miss, and a lot to be familiar with as a DevOps SRE or platform engineer.

60
00:08:17,590 --> 00:08:19,310
And here comes Checkout.

61
00:08:19,310 --> 00:08:22,890
So Checkout was released on December 2019.

62
00:08:23,210 --> 00:08:35,870
It already has more than 1,000 GitHub stars, 600,000 downloads, tons of best opinionated best practices that comes within it.

63
00:08:35,870 --> 00:08:45,530
So more than 400 checks that are opinionated, are based on the CIS benchmark, SOC2, PCI, and other best practices.

64
00:08:45,530 --> 00:08:50,090
And it has a bunch of CICD integrations.

65
00:08:52,510 --> 00:08:58,230
So what Checkout is doing is giving you a policy as code.

66
00:08:58,230 --> 00:09:05,110
It gives you the ability to define a best practice, and to version the best practice itself.

67
00:09:05,350 --> 00:09:15,190
Where this policy, for example, makes sure everything is encrypted by default, can be peer-reviewed, can be automated as part of this software development lifecycle.

68
00:09:15,330 --> 00:09:21,010
And specifically in Checkout, we decided that policies should be written in a familiar language like Python.

69
00:09:21,570 --> 00:09:24,270
So let's take this example.

70
00:09:24,270 --> 00:09:29,070
We have here a block that defines a database.

71
00:09:29,230 --> 00:09:37,450
And what is missing here is that storage is not encrypted by default on the specific database configuration.

72
00:09:37,450 --> 00:09:40,190
How would a Checkout policy look like?

73
00:09:40,310 --> 00:09:53,290
Well , when creating a custom policy, you can give it a name, an identifier, the type of resource that you would like to inspect, which is AWS DB instance, a category, which is encryption.

74
00:09:53,290 --> 00:10:02,130
And the scan itself is just, let's look for storage encrypted and make sure that it equals true.

75
00:10:02,350 --> 00:10:04,590
If it does, let's pass it.

76
00:10:04,610 --> 00:10:06,690
Otherwise, let's fail the check.

77
00:10:07,250 --> 00:10:14,870
And Checkout is doing all of the wrapping of making a very clear reporting option, a very clear CI integration.

78
00:10:14,930 --> 00:10:20,450
And we'll take a look on how does that look like on CLI.

79
00:10:21,050 --> 00:10:30,450
So what I'm going to do now is I'm going to demonstrate Checkout on a vulnerable by design project called TerraGoat.

80
00:10:30,450 --> 00:10:36,250
And if we will have time, we'll do the same for Kubernetes Goat and CloudFormation Goat.

81
00:10:36,310 --> 00:10:39,550
So let's spin up the demo.

82
00:10:41,760 --> 00:10:43,120
All right.

83
00:10:43,120 --> 00:10:49,600
So what I have here is just a very simple terminal.

84
00:10:49,600 --> 00:10:50,660
I'm using Mac.

85
00:10:50,660 --> 00:10:59,200
Before this talk, I've executed brew install Checkout or pip install Checkout.

86
00:10:59,200 --> 00:11:01,240
Both would work for you.

87
00:11:01,520 --> 00:11:07,040
And what I have here are those three projects of vulnerable by design infrastructure.

88
00:11:07,380 --> 00:11:14,100
But even on regular open source module, you will likely find a misconfig.

89
00:11:14,100 --> 00:11:20,460
So let's dive into TerraGoat and take a look on the project structure.

90
00:11:20,460 --> 00:11:28,800
So I have a Terraform directory that has resources among the three cloud providers.

91
00:11:28,800 --> 00:11:39,300
Specifically on AWS, I have a Terraform file for S3 buckets.

92
00:11:39,440 --> 00:11:45,520
So over here I have a bucket that is public, not encrypted, without access log and without versioning.

93
00:11:46,600 --> 00:11:56,800
And I have another file for EC2 instances that has plain text access keys.

94
00:11:56,980 --> 00:12:03,620
But if I wouldn't tell you that, it would have taken you a lot of time to see that.

95
00:12:03,620 --> 00:12:08,460
So let's run Checkout and see what it can do.

96
00:12:09,240 --> 00:12:12,900
So the basic parameter is minus D.

97
00:12:12,900 --> 00:12:18,540
Choosing a directory that Checkout will scan the infrastructure's code for.

98
00:12:18,960 --> 00:12:27,780
So what I'm going to do is I'm going to scan the AWS directory and see how the results look like.

99
00:12:28,660 --> 00:12:30,920
So it should take a few seconds.

100
00:12:30,920 --> 00:12:41,580
And what Checkout found here is 58 passing checks, meaning 58 times that cloud resources were with best practices on.

101
00:12:41,580 --> 00:12:44,080
And 53 failchecks.

102
00:12:44,080 --> 00:12:48,560
So over here I can see all of those passing use cases.

103
00:12:48,800 --> 00:12:53,860
So I have here a database application that is not open on RDP port, which is good.

104
00:12:53,860 --> 00:12:55,180
I've done some good work.

105
00:12:55,180 --> 00:12:59,440
But if I want to on the bad things that it has found.

106
00:12:59,700 --> 00:13:03,280
So over here I have a bucket that is not encrypted at rest.

107
00:13:03,280 --> 00:13:06,720
And this is why we have a failed check.

108
00:13:07,740 --> 00:13:12,320
And the resource is defined between line 1 and 13.

109
00:13:12,320 --> 00:13:13,480
And I can see it here.

110
00:13:13,480 --> 00:13:16,420
And I can see that there is no encryption block.

111
00:13:16,420 --> 00:13:18,980
I've also written it to myself as a comment.

112
00:13:19,640 --> 00:13:29,800
And if I'll take a look on the next set of resources that are right after S3, here I have an unencrypted RDS.

113
00:13:29,800 --> 00:13:31,980
And that is publicly accessible.

114
00:13:33,620 --> 00:13:40,300
And also plain text access keys found in this EC2 block.

115
00:13:40,300 --> 00:13:41,560
Here they are.

116
00:13:42,680 --> 00:13:45,900
Why is plain text access keys bad?

117
00:13:45,900 --> 00:13:49,280
Because they're often used for crypto mining attack.

118
00:13:49,280 --> 00:13:53,180
People can take those access keys and deploy a crypto miner.

119
00:13:53,180 --> 00:13:56,860
And basically my AWS bill will go up and up and up.

120
00:13:57,720 --> 00:13:58,860
All right.

121
00:13:58,860 --> 00:14:03,020
So we have installed check off using pip install.

122
00:14:03,020 --> 00:14:06,020
We've executed it on our local director of AWS.

123
00:14:06,020 --> 00:14:09,120
And we found a bunch of issues that we should solve.

124
00:14:10,460 --> 00:14:14,340
But that was like a one time execution.

125
00:14:14,340 --> 00:14:21,280
How do I make sure that check off will run on each and every change that I'm doing to my infrastructure as code?

126
00:14:21,360 --> 00:14:25,080
And I want check off to tell me, hey, you have this specific issue.

127
00:14:25,080 --> 00:14:31,080
You should solve it before committing it to your GitHub account.

128
00:14:31,300 --> 00:14:33,260
And from there to the production.

129
00:14:33,800 --> 00:14:41,520
So what check off has is actually a pre-commit integration where you can do exactly that.

130
00:14:41,520 --> 00:14:43,780
You can configure a pre-commit hook.

131
00:14:44,220 --> 00:15:04,200
And on that scenario, before each commit, check off will scan your local directory, your local repository, and will prevent you from committing that bad code into your GitHub if it does not follow those best practices.

132
00:15:04,280 --> 00:15:07,620
So let's take a look on how does that look like.

133
00:15:09,780 --> 00:15:19,880
So if I go up here, and what I have configured is a pre-commit config YAML.

134
00:15:20,240 --> 00:15:27,940
Mentioning that I should run the latest version of check off always on every commit.

135
00:15:27,940 --> 00:15:38,200
So what I've done before this talk is I've created a new Terraform file called S3 new.

136
00:15:38,540 --> 00:15:40,620
And it's not committed.

137
00:15:40,660 --> 00:15:43,120
Let's try to commit it.

138
00:15:45,200 --> 00:15:54,180
So what the pre-commit hook is doing right now is running check off upon commit.

139
00:15:54,180 --> 00:15:55,840
And it fails my commit.

140
00:15:55,840 --> 00:16:06,900
I cannot push new code to my source control unless it fixes those issues that are found in my S3 new Terraform file.

141
00:16:07,680 --> 00:16:09,140
Which is cool.

142
00:16:09,140 --> 00:16:13,680
Now I don't need to run check off manually on each and every change.

143
00:16:13,840 --> 00:16:17,460
I can just install the pre-commit hook.

144
00:16:17,460 --> 00:16:24,100
And now my workstation cannot upload bad S3 buckets.

145
00:16:24,760 --> 00:16:26,520
All right.

146
00:16:26,520 --> 00:16:27,800
So we have that.

147
00:16:27,800 --> 00:16:29,640
The misconfig is gone.

148
00:16:29,980 --> 00:16:36,800
And I cannot use my workstation to write bad Terraform code.

149
00:16:36,820 --> 00:16:41,660
But what about workstations that did not deploy a pre-commit hook?

150
00:16:43,500 --> 00:16:49,840
The best way to handle that use case is to install check off also in your CI CD pipeline.

151
00:16:50,480 --> 00:16:58,260
Where on each change request, pull request, check off will execute as part of your CI.

152
00:16:58,940 --> 00:17:03,980
And we'll call that check off job, for example, infrastructure security tests.

153
00:17:03,980 --> 00:17:07,100
And it works just like any unit test.

154
00:17:07,100 --> 00:17:13,680
Where you're running application tests, you can do the same with those 400 best practices of check off.

155
00:17:14,880 --> 00:17:26,120
If check off approves or if the test passes successfully, you can deploy your infrastructure code to production.

156
00:17:26,120 --> 00:17:32,020
If check off fails, on the other hand, it will block your pull request from being merged.

157
00:17:32,020 --> 00:17:36,040
Just like unit tests that are blocked from being merged.

158
00:17:36,360 --> 00:17:49,340
So to do that specific piece, we have developed actually a community contributed piece is a check off action.

159
00:17:49,560 --> 00:17:53,360
Let's take a look on how it looks like.

160
00:17:58,930 --> 00:18:10,630
So if you go to BridgeCrew.io check off action, you can see a project that is contributed by this handsome fellow called Chris Mavarkis.

161
00:18:11,350 --> 00:18:18,750
And to configure a check off action in your GitHub action is as simple as that.

162
00:18:18,750 --> 00:18:25,490
You just reference this specific action on your GitHub.

163
00:18:25,730 --> 00:18:35,590
And you can choose which checks to run, whether to run them all, skip a specific one, scan a specific directory, or use any of the other flags that check off has.

164
00:18:36,170 --> 00:18:47,790
And if you actually do that and enhance that into your CI pipeline, assuming it's on GitHub action, it will look like this.

165
00:18:47,790 --> 00:18:56,270
So over here I have a pull request on a repository that demonstrates a GitHub action of check off.

166
00:18:57,150 --> 00:19:06,230
So here I have created a bunch of resources to create a new web server in Terraform.

167
00:19:06,230 --> 00:19:22,270
So I have this AWS instance and the GitHub action have added annotations to my code saying, hey, your AWS instance has hardcoded access keys and it's using unencrypted EBS.

168
00:19:22,270 --> 00:19:26,350
And I should really solve those issues here in that code block.

169
00:19:26,430 --> 00:19:34,230
And I also have issues with my security group, which has port 22 open to the entire internet.

170
00:19:34,570 --> 00:19:36,770
And I should really solve that too.

171
00:19:37,350 --> 00:19:44,990
So check off will do a set of annotations for each and every resource that is violating those best practices.

172
00:19:51,690 --> 00:20:01,730
So I have this pretty CI pipeline that will check each and every commit.

173
00:20:01,730 --> 00:20:10,590
Not only if I'm doing that on my endpoint, but also if I'm doing that directly on GitHub or from an endpoint that does not have pre-commit hook deployed on.

174
00:20:14,250 --> 00:20:22,290
So what if I want to see the same being done for Kubernetes?

175
00:20:23,130 --> 00:20:34,030
So there is actually a very cool additional project, very similar to Terracode, that is about Kubernetes configuration.

176
00:20:34,150 --> 00:20:42,170
So it is a project created by Madhu and it's called Kubernetes code.

177
00:20:42,170 --> 00:20:50,410
It has some amazing scenarios of bad configured Kubernetes deployment manifests.

178
00:20:50,650 --> 00:21:04,470
And it has also a great Katakoda work through that I really recommend doing just to get familiar with what are the best practices and bad practices when configuring a Kubernetes cluster or a job.

179
00:21:04,490 --> 00:21:11,550
What I have here on my local endpoint is actually this

180
00:21:15,420 --> 00:21:17,480
project already cloned.

181
00:21:18,120 --> 00:21:24,680
And what I'm going to do is I'm going to run chkov-d kubernetes-code.

182
00:21:30,070 --> 00:21:35,030
I'm going to run chkov-d on the scenarios directory.

183
00:21:35,050 --> 00:21:39,630
And I've actually created my own scenario just before this talk.

184
00:21:40,070 --> 00:21:43,330
And I'm going to see what the results look like.

185
00:21:43,330 --> 00:21:50,550
So chkov will now do the same that it has done for Terraform, but now for Kubernetes manifests.

186
00:21:50,930 --> 00:21:57,130
So we have here a bunch of issues on my deployment channel.

187
00:21:57,130 --> 00:21:59,090
I like a lot of them.

188
00:21:59,150 --> 00:22:05,710
I have here service account tokens that are mounted not when necessary.

189
00:22:06,250 --> 00:22:10,890
I have UID conflicts.

190
00:22:10,890 --> 00:22:18,030
I have usage of root on my containers.

191
00:22:18,090 --> 00:22:23,770
And I should really solve all of those deployments configurations across my pods.

192
00:22:24,570 --> 00:22:50,730
The one thing that is nice, if you're not familiar with that specific configuration and what's the rationale behind it and how to solve it, you can always go to those documentation pages that we have publicly made accessible explaining what's the rationale behind this specific check and how to automate the remediation of that specific configuration.

193
00:22:50,830 --> 00:22:57,130
So let's say that you're encountering a specific config and you don't realize why you need to solve it.

194
00:22:57,130 --> 00:23:04,650
Here's the explanation where you have the step-by-step guidelines to fix that.

195
00:23:05,010 --> 00:23:12,530
And obviously if you want to try to fix that automatically, you can try the platform, but you can also use only the open source tools.

196
00:23:13,450 --> 00:23:29,090
As for the last piece, there is actually a very cool way to use checkup for reporting mechanism, just like reporting over passing and failing unit tests.

197
00:23:29,090 --> 00:23:34,190
Checkout has a reach output format that has JUnit XML.

198
00:23:34,270 --> 00:23:43,670
And if you integrate that into a CI system like AWS CodeBuild, you can actually get a very nice report showing the amount of passing and failing.

199
00:23:43,670 --> 00:23:51,390
And in some systems like Jenkins, also to show the trend over time of those configurations.

200
00:23:53,550 --> 00:23:58,910
Yeah, so I guess that's more or less about it on Checkov.

201
00:23:58,950 --> 00:24:13,650
Just to give some more references of how to use it, you can always go into Checkov.io, start on the installation page and getting started, which is the pip install piece.

202
00:24:14,210 --> 00:24:24,650
And right after you have those next chapters that explains to you what are the existing resource scans.

203
00:24:24,770 --> 00:24:36,050
So Checkov has a list of let's see 422 best practices that are opinionated that you can execute.

204
00:24:36,050 --> 00:24:46,310
But if you want to ignore some of those and run only specific ones, you can always suppress tests that you won't like to see.

205
00:24:46,310 --> 00:25:12,570
For example, if you have a public bucket and it should be public for website assets, you can just use a very similar annotation to the one that you would use for JUnit test, for example, or PyTest, which is Checkov skip, mentions the Check ID and a description of why this resource should not adhere these best practices.

206
00:25:13,250 --> 00:25:23,330
So over here I have an S3 bucket that should be public because it's serving as a static hosting for web content.

207
00:25:24,190 --> 00:25:37,890
And you can do a very similar thing using a Kubernetes annotation and mention why you want to skip a specific check and then Checkov will not fail on that specific Check ID.

208
00:25:38,770 --> 00:25:57,610
There is some documentation also of how to integrate Checkov with CI systems like GitHub Actions, Jenkins, GitLab CI, and also screenshots of how that looks like on those specific environments.

209
00:25:59,000 --> 00:26:05,970
All right, so if you have any questions, now would be a great time.

210
00:26:05,970 --> 00:26:22,990
I really encourage you to try our open source tools, follow our blog where we update on those, and if you have any questions on contributions that you'd like to make, feel free to reach out over email or Twitter.

211
00:26:23,650 --> 00:26:26,490
I would be more than happy to do so.

212
00:26:26,490 --> 00:26:29,990
Just a quick question for me, what's next for Checkov?

213
00:26:29,990 --> 00:26:35,010
Any other integrations that are in the works or any additional new features?

214
00:26:35,430 --> 00:26:42,210
Right, so we had a bunch of requirements coming from the community.

215
00:26:42,210 --> 00:26:44,070
Some have asked for...

216
00:26:44,070 --> 00:26:46,850
So the latest feature is actually ARM templates.

217
00:26:46,850 --> 00:26:57,430
We added ARM templates to Checkov so you can use it not only for Terraform or CloudFormation Kubernetes, but also for this one.

218
00:26:57,550 --> 00:27:07,050
And we also got requirements from the community for Ansible, and I think that's the big next manifest probably.

219
00:27:07,470 --> 00:27:15,190
We don't have any resources scheduled yet to handle this one, but any contribution would be accepted.

220
00:27:17,010 --> 00:27:27,010
And yeah, it already has most of the CI integrations and Docker, a brew install, so it should be pretty straightforward to use.

221
00:27:27,390 --> 00:27:35,030
Do you think if people used TerraGo modules more, this would help the number of misconfigurations to go down?

222
00:27:35,250 --> 00:27:41,270
So TerraGrant is a do-not-repeat-yourself framework for Terraform.

223
00:27:41,270 --> 00:27:46,530
It's a templating piece that helps to reduce the amount of code that we're writing.

224
00:27:46,550 --> 00:28:02,690
So if you're writing less code, you probably create less misconfigs, but if the templated configuration lacks the right defaults, so it will not reduce that specific piece.

225
00:28:02,690 --> 00:28:05,350
So the answer is yes and no.

226
00:28:05,350 --> 00:28:07,870
Checkov specifically does not support TerraGrant.

227
00:28:09,210 --> 00:28:13,230
Completely, but it does show value in some cases.

228
00:28:13,230 --> 00:28:19,370
So if you have a TerraGrant project, I would be more than happy to see the results of Checkov on it.

229
00:28:19,370 --> 00:28:26,110
We're researching how to make it work even better with templated modules.