Change iac gen-driftignore to iac update-exclude-policy

[eliecharra]

• Follows CONTRIBUTING rules

What does this PR do?

This PR move the responsibility to generate drift exclusion rule from driftctl to snyk CLI.
We are now generating our own rules in the snyk policy file instead of using driftctl to generate a .driftignore
More context about that choice in the Jira ticket.

Where should the reviewer start?

src/cli/commands/update-exclude-policy.ts

How should this be manually tested?

$ cat test/fixtures/iac/drift/analysis.json | bin/snyk iac update-exclude-policy

Ensure your .snyk file is update with those new exclude rules

+exclude:
+  iac-drift:
+    - aws_iam_access_key.AKIA5QYBVVD25KFXJHYJ
+    - aws_iam_user.test-driftctl2
+    - aws_iam_access_key.AKIA5QYBVVD2Y6PBAAPY
+    - aws_s3_bucket_policy.driftctl
+    - aws_s3_bucket_notification.driftctl

Any background context you want to provide?

The exclude logic is based on this code from driftctl

Changes in help files are just FYI here, changes are in a draft PR in gitbook

What are the relevant tickets?

https://snyksec.atlassian.net/browse/CFG-1669

Screenshots

Additional questions

[github-actions]

	Warnings
⚠️	Please make changes to snyk help text in Gitbook. Changes will be automatically synchronised to Snyk CLI as a scheduled PR. For more information, see: help/README.md.

Generated by 🚫 dangerJS against 9ac4cf1

[ghost]

This PR modifies files linked to issues tracked in Stepsize. You might want to review their status, priority, and scope.

We are losing types because of hotloading components in a JS file

• src/cli/commands/index.js

_{Mention [stepsize] in a comment if you'd like to report some technical debt. See examples here.}

[craigfurman]

Looking good! This works in the case where there is already a .snyk file present, but errors with ENOENT when it does not. snyk ignore doesn't have this problem. We might want to touch the file first (unconditionally, idempotently).

Also, I noticed some stderr output from driftctl: "Hint: use gen-driftignore command to generate a .driftignore file based on your drifts". We might want to suppress / manipulate this before printing it for the user, to use this new command. WDYT?

[aron]

👍 looks good to me.

[eliecharra]

Looking good! This works in the case where there is already a .snyk file present, but errors with ENOENT when it does not. snyk ignore doesn't have this problem. We might want to touch the file first (unconditionally, idempotently).

Fixed, I used the same logic than the ignore cmd.

Also, I noticed some stderr output from driftctl: "Hint: use gen-driftignore command to generate a .driftignore file based on your drifts". We might want to suppress / manipulate this before printing it for the user, to use this new command. WDYT?

Yeah we can probably either remove that sentence from the engine, or check if we are wrapped in the snyk CLI and hide it only in that case.
I'm not sure that the second approach (basically doing if (isWrappedBySnyk) { ... }) is really something that we want.
I'm afraid that starting doing that will lead us to have a ton of if snyk statements everywhere in the engine, and that will finally bloat it a lot WDYT @craigfurman ? 🤔

[aron]

Yeah we can probably either remove that sentence from the engine, or check if we are wrapped in the snyk CLI and hide it only in that case.

Definitely agree with avoiding having anything snyk specific in the drift codebase. My understanding is that we want to aim for the drift -> snyk communication to be essentially machine to machine right? So perhaps we just need a flag or an environment variable to suppress "user info" output or help text.

[craigfurman]

LGTM 🥳

Yeah we can probably either remove that sentence from the engine

If that's an option, then I reckon we should do it. Less noise and all...

I'm not sure that the second approach (basically doing if (isWrappedBySnyk) { ... }) is really something that we want

IMO that's definitely not something we want, but it also isn't what I was suggesting! I was suggesting doing string replacement in this CLI on the stderr that it receives from driftctl. But if removing the message is an option, I prefer that one.

[eliecharra]

If that's an option, then I reckon we should do it. Less noise and all...

Done here snyk/driftctl#1449
Let's discuss on this other PR if we want to wrap that in the --quiet flag or not