Demo/proof of concept of using Snyk with Pulumi Policy as Code:
- The code in the
infradirectory creates adocker.Imageresource based on thedebianimage, which has known vulnerabilities. Thedocker.Imageis set to build (but not push to a remote repo) onpulumi preview. - The code in the
policydirectory contains a Pulumi Policy Pack which calls the Snyk CLI. If the Snyk CLI fails (e.g. because it detects vulnerabilities), the resource will be considered in violation and thepulumi preview(orpulumi up) operation will fail.
To run the demo:
cd infra
pulumi preview --policy-pack ../policySnyk can scan Dockerfiles for vulnerabilities. Because there's no direct relationship between the location on disk of a Pulumi program and any policy packs that might be running, we need to configure the Snyk policy to know where the Pulumi program is running.
./add-dockerfile-scanning.shBecause Dockerfile scanning requires the absolute path to the Pulumi program to be supplied via policy configuration, server-side policy enforcement requires that the Pulumi program be run from a known location on disk (i.e. whatever the path on disk is that the policy is configured with in the Pulumi Cloud console) if Dockerfile scanning is desired. If pulumi/pulumi-policy#333 is implemented, this restriction can be lifted and the configuration value can be removed.
If the Snyk CLI gives you an error similar to the following:
connect ENOENT /var/run/docker.sock
You may need to set the DOCKER_HOST environment variable. At the time of writing, the Snyk CLI appears to assume that the Docker socket is running in the older (privileged) location. The newer version of Docker use a socket placed in the current user's home directory, e.g.:
export DOCKER_HOST=unix:///Users/jkodroff/.docker/run/docker.sock
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent