New command "mark-trusted"

[hjacobs]

Add a new command in the CLI to mark images as "trusted".

1. user runs pierone mark-trusted myteam myartifact 1.0
2. show current scm-source information to user ask him/her to verify the scm-source information
3. call Pier One API to set the trusted flag to true

[juhmelo]

How can we set trusted to true if only one person verifies? Shouldn't it require two people to verify the scm-source information, since after a image is trusted it can be deployed to production targets?

[lotharschulz]

@juhmelo : a regarding zalando internal tickets states regarding your point:

at least one (Zalando) employee to verify if the scm source information is correct, no trust if no scm-source file in Docker image

[gpodolan]

Will a health check of the scm-source information be performed (e.g.: git hash really a hash)? It would be good if we can show, together with the information itself, a status (OK, NOK).

If we can do that, then one approval should suffice, even though it can come from the same person who created the image. This is due to the fact that this approval is an addition to the Zappr ones, and not a replacement. Since there will be a constraint that the approver is in the employee realm (if I recall correctly from our meeting), we are able to establish accountability for the whole chain.

What we can do is have a message outlining what means to make an image trusted so people are aware of what they are signing up for.

[lotharschulz]

Will a health check of the scm-source information be performed (e.g.: git hash really a hash)?

I am unsure if I understand:

Do you envision git diff --quiet || echo 'dirty' or git status --short to check if the repo was dirty or contains untracked files?

It would be good if we can show, together with the information itself, a status (OK, NOK).

Do you refer to the information the pierone cli returns e.g.

$ pierone tags automata pierone --url=registry.opensource.zalan.do        
Team    │Artifact│Tag      │Created │By                                         │Fixable CVE Severity│Unfixable CVE Severity
automata pierone  master-16 129d ago credprov-cdp-controller-proxy_pierone-token LOW                  HIGH                   
automata pierone  master-17 121d ago credprov-cdp-controller-proxy_pierone-token LOW                  HIGH                   
automata pierone  master-18  22d ago credprov-cdp-controller-proxy_pierone-token NOT_PROCESSED_YET    NOT_PROCESSED_YET      

$ pierone tags automata pierone --url=registry.opensource.zalan.do -o json 
[{"artifact": "pierone", "created_by": "credprov-cdp-controller-proxy_pierone-token", "created_time": 1517927808.165, "severity_fix_available": "LOW", "severity_no_fix_available": "HIGH", "tag": "master-16", "team": "automata"}, {"artifact": "pierone", "created_by": "credprov-cdp-controller-proxy_pierone-token", "created_time": 1518621490.039, "severity_fix_available": "LOW", "severity_no_fix_available": "HIGH", "tag": "master-17", "team": "automata"}, {"artifact": "pierone", "created_by": "credprov-cdp-controller-proxy_pierone-token", "created_time": 1527175274.199, "severity_fix_available": "NOT_PROCESSED_YET", "severity_no_fix_available": "NOT_PROCESSED_YET", "tag": "master-18", "team": "automata"}]

with an additional column scm-source-check ?

Until I understand your concern I'd say this one should be limited to show the scm-source information as is. A user can check the referenced commit in ghe or gh.com, in case he wants to know more about the git repo at the build time already now.

[gpodolan]

I will ask for some help from @harti2006 on this one. He can probably describe it better than I. His summary was "to show a sanity check of the scm-source.json". Not sure if this helps.

[harti2006]

The sanity checks that I think of:

• is scm-source info present
• is it syntactically correct, according to https://stups.readthedocs.io/en/latest/user-guide/application-development.html#scm-source-json
  • is url a valid git url?
  • is revision a full commit hash (not an abbreviated one)
• is it semantically correct?
  • status is clean (empty)

If those requirements are not met, the traceability chain is broken and the image must not be marked as trusted.

[lotharschulz]

Thanks, I now understand the concern. I created a new issue scm-source sanity check for mark trusted This one stays in its original state.