How do I expose new variables in the CIS Service Catalog?

[pete0emerson]

In the CIS Service Catalog, I would like to be able to have a few variables available for me to configure:

1. retention_in_days for the aws_cloudwatch_log_group resource

The default value is 731 and doesn't make sense for us in our dev and stage accounts

2. max_aggregation_interval for the aws_flow_log resource

The default value is 600, and we need to change this to 60 four our prod account

What is the best way to move forward quickly? What are the alternatives (with pros and cons)?

---

Tracked in ticket #110299

[pete0emerson]

I'll address the question generally, and then dive into this specific example.

Options

Pull Requests

First, we appreciate PRs. When talking about the CIS Service Catalog, that is a wrapper around the non-CIS Service Catalog, which in turn brings together modules from our IaC Library.

In some cases, variables may be exposed at the lowest module level but not propagated up to the Service Catalog (and therefore not up to the CIS Service Catalog). In those cases, the variables would need to be propagated up the chain.

In other cases, variables may not be exposed at all at the lowest module level. In those cases, the variable would need to be added at all levels (module, Service Catalog, CIS Service Catalog).

In most cases, we'll review your PRs, make sure that it passes our standards (tests, et cetera), and then merge them in and release.

Feature Request

You can ask us to do this. We'll put it into our queue and triage it and then, if we decide that it merits inclusion in our code base, we'll build it out, issue pull requests, approve, merge, and release. We do not strive to include every single variable for every single resource in our modules. But we also want to suit the needs of our customers, so we'll usually help you out.

Fork the repo(s)

You can fork the repo(s) (at any or all levels) and make your own changes.

Write your own module

You could also write your own module or directly put the resources you need in your code base, with the features you need.

Comparing the options

Forking may seem like the fastest way to get this done. Indeed, if you need this yesterday, it may be. But now your code base drifts away from ours, and you won't be able to take advantage of our updates as easily. You'd need to manage the differences between our code and yours.

Writing your own module faces the same problems as forking; you'll need to maintain it.

Issuing a PR is the second fastest method, and as long as your PRs get merged, then the beauty is that we continue to maintain the code base moving forward, and you don't have to point your code base at your forks. You will have to update your code base to point at the newest version of the repo.

Your specific case

retention_in_days for the aws_cloudwatch_log_group resource

1. retention_in_days is not exposed in the CIS Service Catalog.
2. retention_in_days is not exposed in the non-CIS Service Catalog.
3. retention_in_days is exposed here in the vpc-flow-logs module in the terraform-aws-vpc repository. It is configured by the cloudwatch_log_retention variable.

This variable would need to be plumbed up to the non-CIS Service Catalog and passed on to the CIS Service Catalog.

max_aggregation_interval for the aws_flow_log resource

1. max_aggregation_interval is not exposed in either Service Catalog, and it is also not exposed in the vpc-flow-logs module in the terraform-aws-vpc repository. It is an optional parameter for the aws_flow_log resource, we're just not currently leveraging it.

This variable would need to be added to in all three places (terraform-aws-vpc/modules/vpc-flow-logs, non-CIS Service Catalog, and CIS Service Catalog).

[gberlot-luna]

@pete0emerson If we need plumbed up a variable to the non-CIS Service Catalog and passed on to the CIS Service Catalog, what's the procedure. Do we have to change the code or can we ask about it? Is there any documentation about how to do this?

[pete0emerson]

I can take care of this for you. I've just released max_aggregation_interval in the vpc-flow-logs module, and what I'll do next is propagate those up to the service catalog and the CIS service catalog.