|
1 | 1 | ### Background |
2 | 2 |
|
3 | | -Atomist keeps tracks of checks that are performed on container images. Examples of checks include the following. |
| 3 | +Atomist keeps track of the state of container images by continuously evaluating rules in your Image Policy. For example: |
4 | 4 |
|
5 | 5 | * Does the image have the required `LABEL`s? |
6 | 6 | * Was the image created by a trusted builder? |
7 | 7 | * Was the image created from a known git commit sha? |
8 | 8 | * Has the image been scanned for vulnerabilities? |
9 | 9 | * Does the image contain any vulnerabilities that are not already present in the currently running version? |
10 | 10 |
|
11 | | -Each workload can define a set of mandatory checks. This allows Atomist to wait for a new image to have all the necessary checks and then signal to a workload that a new candidate version is ready. This works well with a gitops workflow where new candidate images can be pulled into a workload once they are ready. Failing checks are made available to developers to indicate why a change was rejected, and these same checks drive tools like kubernetes admission controllers, to ensure that only fully checked images are admitted to selected namespaces. The combination of gitops controllers, admission controllers, and pluggable image checks, gives teams the ability to plug consistent validation into their cloud native delivery. |
| 11 | +Each workload can define a set of mandatory rules. This allows Atomist to wait for a new image to have all the necessary rules satisifed and then signal to a workload that a new candidate version is ready. This works well with a gitops workflow where new candidate images can be pulled into a workload once they are ready. Failing rules can be made available to developers via GitHub Checks to indicate why a change was rejected, and these same rules drive tools like kubernetes admission controllers, to ensure that only images that fully satisfy your policy are admitted to selected namespaces. The combination of gitops controllers, admission controllers, and pluggable image policy, gives teams the ability to plug consistent validation into their cloud native delivery. |
12 | 12 |
|
13 | | -### Enable Vulnerability Check |
| 13 | +### Enable Vulnerability GitHub Check |
14 | 14 |
|
15 | 15 | Start by checking whether a candidate image has additional vulnerabilities when compared to other versions already in existing workloads. If you're building an image from a pull request commit, this policy will also compare vulnerabilites against any image built from the HEAD commit of your default branch. [Enable the policy][settings] by navigating to your [settings page][settings]. |
16 | 16 |
|
17 | | -In the section called `New Image Vulnerabilites`, select the check box that controls whether a GitHub check run should fail when _new_ critical or high severitare found. |
| 17 | +In the section called `New Image Vulnerabilites`, select the check box that controls whether a GitHub Check should fail when _new_ critical or high severitare found. |
18 | 18 |
|
19 | 19 |  |
20 | 20 |
|
21 | | -[settings]: https://dso.atomist.com/r/auth/policies |
22 | | - |
23 | | -### Choose Admission Checks |
24 | | - |
25 | | -Now that we are checking images for new vulnerabilities, we can begin requiring that certain sets of checks pass before an image is ready to be admitted into an existing workload (for example, see the [section on kubernetes admission control](admission-control.md)). We can select different checks for different environments. For example, let's start with the requirement that a kubernetes cluster named `demo` with a namespace `production` requires the check configured above. |
26 | | - |
27 | | -This can be done by editing the [Deployment Policy](https://go.atomist.com/r/auth/manage/integrations/s/l/atomist/deploy-integration) and adding: |
28 | | - |
29 | | -`demo/production:github/docker-vulnerability-policy` to the list of checks in the **Image Policy**: |
30 | 21 |
|
31 | | - |
32 | 22 |
|
33 | | -#### Configuration via GraphQL |
| 23 | +### Choose Admission Rules |
34 | 24 |
|
35 | | -We can also configure by calling a GraphQL mutation. Copy the following mutation into a file (e.g. rules.json) |
| 25 | +Policies are made up of sets of rules. Atomist comes with some built-in rules, but GitHub Checks can also be used directly as rules in policies. This makes it easy to compose policies from GitHub Checks created by other processes, such as CI/CD systems, to ensure for example, that images have been properly tested, that commits have been signed and so on. |
36 | 26 |
|
37 | | -```bash |
38 | | -cat <<'EOF' > rules.json |
39 | | -{"rules": ["demo/production:github/docker-vulnerability-policy"]} |
40 | | -EOF |
41 | | -``` |
| 27 | +Now that we are checking images for new vulnerabilities, we can begin requiring that certain sets of rules pass before an image is ready to be admitted into an existing workload (for example, see the [section on kubernetes admission control](admission-control.md)). We can select different rules for different environments. For example, let's start with the requirement that a Kubernetes cluster named `demo` with a namespace `production` requires the GitHub Check configured above. |
42 | 28 |
|
43 | | -Now execute the scripts below: |
| 29 | +From the [policy view][settings], click the "Add first deployment policy" and and add the new GitHub Check we created above: |
44 | 30 |
|
45 | | -```bash |
46 | | -ATOMIST_WORKSPACE_ID=<workspace-id> |
47 | | -ATOMIST_API_KEY=<api-key> |
48 | | -``` |
49 | | - |
50 | | -* `workspace-id` |
51 | | - * Grab your workspace ID from https://dso.atomist.com/r/auth/policies |
52 | | -* `api-key` |
53 | | - * Used to authenticate with the Atomist API and managed here https://dso.atomist.com/r/auth/integrations |
54 | | - |
55 | | - |
56 | | -```bash |
57 | | -cat <<'EOF' > policy.graphql |
58 | | -mutation setPolicy($rules: [String!]!) { |
59 | | - setConfigurationParameter( |
60 | | - name: "deploy-integration", |
61 | | - namespace: "atomist", |
62 | | - parameter: {stringArray: |
63 | | - {name: "check-names", |
64 | | - value: $rules}}, |
65 | | - configurationName: "policy-cfg") |
66 | | - { |
67 | | - configured { |
68 | | - skills {id} |
69 | | - } |
70 | | - } |
71 | | -} |
72 | | -EOF |
73 | | - |
74 | | -curl -X POST \ |
75 | | - -d '{"query": "'"$(sed 's/"/\\"/g' < policy.graphql)"'", "variables": '"$(< rules.json)"'}' \ |
76 | | - -H "Authorization: Bearer ${ATOMIST_API_KEY}" \ |
77 | | - -H "Content-Type: application/json" \ |
78 | | - https://automation.atomist.com/graphql/team/${ATOMIST_WORKSPACE_ID} |
79 | | -``` |
| 31 | + |
80 | 32 |
|
| 33 | + |
81 | 34 |
|
| 35 | +[settings]: https://dso.atomist.com/r/auth/policies |
0 commit comments