Description
The docs confused me a bit today: the Renderers page lists the gpg renderer as a text renderer. At the same time the salt.rendereres.gpg page uses it as a data renderer (last in the pipeline). This confused me for

Docs
(CDK v1.94.1)
https://docs.aws.amazon.com/cdk/api/latest/docs/aws-codepipeline-actions-readme.html#aws-s3-source

Using the example for se

Requesting that you add the new Gitlab Provider as a new VCS Provider.

See here for the provider details: https://registry.terraform.io/providers/gitlabhq/gitlab/latest

Terraform resources can be created using for_each or count. This creates an array of resources. We could support setting usage values for all elements of the array by using a wildcard like this:

resource_usage:
  aws_cloudwatch_log_group.loggroup[*]:
    ...

I think expected functionality would be that the usage value should apply individually to each element of the array

Describe the bug
CKV_GCP_14 requires a backup configuration, but it does not take into consideration read replicas.
A read replica cannot have backup enabled in GCP.

To Reproduce
Steps to reproduce the behavior:

1. Create a google_sql_database_instance with master_instance_name and replica_configuration
2. Chekov will pop up error CKV_GCP_14

Expected behavior
Read replicas

• terrascan version:
  docker.io/accurics/terrascan@sha256:cf459ae515849f2c004308c1a924958c3f92b121c94d64dcfac3849ce09b00b3

• Operating System:
  Docker

Description

When used in a pipeline, need to add full path otherwise it fails with an error. Would be logically if the Docker image's PATH environment variable had /go/bin in it.

What I Did

Images used:
    build 

Right now even if the manifest is malformed, for example, some incorrect indentations, we won't error out. This could be very a pain because users are not aware that their settings will not be rendered. We should probably error out earlier before CFN deployment.

Garbage collection works by listing everything with the gc-tag. In a busy cluster, we really want that filter to happen server-side and ideally using an index of some sort.

That means we should use a Kubernetes label, not an annotation.

I think this will require a two-step migration plan (write both but continue to read annotation; release; drop support for annotation; release).