Doc section on "security by sysadmin" #1653

Merged
merged 4 commits into from Nov 10, 2016

Conversation

Projects
None yet
6 participants
@delocalizer delocalizer * section on "security by sysadmin"
2b64a80

delocalizer changed the title from * section on "security by sysadmin" to * doc section on "security by sysadmin" Nov 8, 2016

Contributor

kcibul commented Nov 8, 2016

Thanks for the contribution! @katevoss @geoffjentry can we get a quick review?

kcibul changed the title from * doc section on "security by sysadmin" to Doc section on "security by sysadmin" Nov 8, 2016

Contributor

cjllanwarne commented Nov 8, 2016

IMO if we put any security recommendations in our README we should be very careful to disclaimer it. Heavily. Maybe with something along the lines of:

Warning! 
- Only YOU are responsible for your own security! 
- Cromwell is NOT a security appliance! 
- What follows are ideas and starting points and not necessarily a secure system configuration in your situation"
@mcovarr

mcovarr approved these changes Nov 8, 2016

@@ -64,6 +66,9 @@ A [Workflow Management System](https://en.wikipedia.org/wiki/Workflow_management
* [Logging](#logging)
* [Workflow Options](#workflow-options)
* [Call Caching](#call-caching)
+ * [Configuring Call Caching](#configuring-call-caching)
+ * [Call Caching Workflow Options](#call-caching-workflow-options)
+ * [Local Filesystem Options](#local-filesystem-options)
@mcovarr

mcovarr Nov 8, 2016

Contributor

Whoops thanks for fixing this omission

README.md
+# Security
+
+Cromwell running in server mode accepts all connections on the configured webservice port. The simplest way to restrict access is by putting an authenticating proxy server in between users and the cromwell server:
+ 1. Configure a firewall rule on the cromwell server host to deny access to the webservice port (e.g. 8000) from all addresses except a secure proxy host. "Secure" here meaning administrator login access only.
@mcovarr

mcovarr Nov 8, 2016

Contributor

I'm not sure I understand the second sentence in this context.

README.md
+
+Cromwell running in server mode accepts all connections on the configured webservice port. The simplest way to restrict access is by putting an authenticating proxy server in between users and the cromwell server:
+ 1. Configure a firewall rule on the cromwell server host to deny access to the webservice port (e.g. 8000) from all addresses except a secure proxy host. "Secure" here meaning administrator login access only.
+ 1. Configure `<YourFavoriteWebProxy>` on the proxy host with `<YourFavouriteAuthMechanism>`, to proxy authenticated traffic from the world to the cromwell server. Using Apache `httpd` web server for example with basic htpassword file-based authentication, the configuration might look something like:
@mcovarr

mcovarr Nov 8, 2016

Contributor

The Cromwell team favors 🇺🇸 spelling over 🇬🇧 , but this sentence uses both for the same word! 😄

@cjllanwarne

cjllanwarne Nov 8, 2016 edited

Contributor

Correction: 5/6 of the Cromwell team favours 🇺🇸 spelling 😛

@delocalizer

delocalizer Nov 8, 2016

Contributor

Yeah, my fingers automatically type the Australian (English) sp, I noticed the first one and fixed for you; the second one escaped me :)

Contributor

delocalizer commented Nov 8, 2016

I'm with @cjllanwarne in favouring some form of disclaimer on this, wanting as little as you to be or feel actually responsible for others' security!

Member

geoffjentry commented Nov 8, 2016

@delocalizer Just so it doesn't seem like I'm being lazy, I wanted to chime in on some of the stuff this has brought up (e.g. the disclaimer) but wanted to chat w/ @katevoss first and we just haven't been able to be mutually free yet today. Worst case it'll happen tomorrow and we can get everything sorted.

Thanks for doing this though, now I'll have to actually make good on my side of the deal ;)

@delocalizer delocalizer * changes as discussed in
73e46da
Member

geoffjentry commented Nov 9, 2016

Discussed with @katevoss - as we don't have our long range documentation plan hashed out yet for now we'll be:

  • Making a separate doc (name tbd) with two initial bits. One is the content from @delocalizer describing a user based setup. We'll make it clear that this is their set up and not ours, both from the indemnity angle that @cjllanwarne was concerned about but more importantly because it helps to demonstrate the vibrant community which is building around Cromwell
  • I'll add a second section describing Firecloud's security model
  • That doc will be linked from the README
  • We'll set up a blog post on the main site describing security/auth options in Cromwell and directly referencing this doc. Readers/users will be encouraged to ask questions, provide alternate suggestions, etc. The security doc (for lack of a better word atm) will be more of a living doc

@delocalizer ... I don't want to make extra work for you here. If you wanted to update this PR to reflect the first and third bullet points great, otherwise I can pick up this PR and do first and third while i'm doing the second. If you're going with the former hold off until I confirm the name of the file :)

Member

geoffjentry commented Nov 9, 2016

Discussed name of the file with @katevoss and we're going to go with SecurityRecommendations.md

delocalizer added some commits Nov 9, 2016

@delocalizer delocalizer * Move security section to separate SecurityRecommendations.md doc
cfd9102
@delocalizer delocalizer * fix TOC
6ad2ca9
Member

geoffjentry commented Nov 10, 2016

This is great, thanks @delocalizer !

The downside of you doing those followups is that now I don't have the open PR staring me in the face reminding me I have to do something ;) I'll try to put in some content re Firecloud in the near future.

@geoffjentry geoffjentry merged commit c23ecb2 into broadinstitute:develop Nov 10, 2016

1 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
code-review/pullapprove Approval required by 2 of: cjllanwarne, francares, gauravs90, geoffjentry, Horneth, jainh, kcibul, kshakir, mcovarr, ruchim
Details
coverage/coveralls Coverage increased (+0.6%) to 71.201%
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment