Security & Android Development Platform

[Mellberg]

I’m working to setup an Android development platform unfortunately
this is new to us and we don’t have much knowledge in how to secure
it.

Our first intentions are to have two separate installs.
- External on DMZ for 3rd party consultants
- Internal on Campus for our own developers

Are there any good way to have this solution setup with fast
replications to and from the external to the internal platform.

Is there any good “best practice” documentation for how to implement
this platform (Git, Gerrit and Hudson) in a secure way which also
would allow external partners to access it?

Not sure if this is the right forum for this type of question.

[Shawn Pearce]

Mellberg <jorgen....@gmail.com> wrote:
> Our first intentions are to have two separate installs.
> - External on DMZ for 3rd party consultants
> - Internal on Campus for our own developers
>
> Are there any good way to have this solution setup with fast
> replications to and from the external to the internal platform.
>

> Is there any good ?best practice? documentation for how to implement

> this platform (Git, Gerrit and Hudson) in a secure way which also
> would allow external partners to access it?

I can't say anything about Hudson, because I don't run a Hudson CI
server myself. But I do know a thing or two about Git and Gerrit.

I don't think we have a great writeup on how to do this
particular case, nor do we have a whole lot of 'best practice'
type documentation. Somebody should really write some. :-)


In your case I would suggest running two different Gerrit installs,
one on the DMZ using perhaps OpenID authentication for the external
partners to authenticate through, and a different Gerrit inside
the corporate firewall, perhaps integrated with your company's
LDAP directory, for your own developers.

The external Gerrit could use a replication.config like the following
to push to the internal server:

[remote "campus"]
url = ssh://dmz-...@campus-host.campus.example.com:29418/${name}.git
refs = refs/heads/*:refs/heads/dmz/*

This will push branches updated on the DMZ server to the campus
server's Gerrit daemon, but the branches will all be prefixed with
"dmz/" in front of them so they don't clash with any non-DMZ (aka
internal) branches.

On the campus server, create a dummy user in the Gerrit database
called 'dmz-host'. You would need to manually insert the records
into the accounts and account_ssh_keys tables to configure this
user account.

Create a group called "DMZ" within the campus server, add the
user account dmz-host to it, and grant it Push Branch +1 .. +3 on
All Projects. This allows the dmz-host user to create or update
branches on the internal server.


Changes which are submitted on the DMZ server will now show up
on the internal server in the corresponding dmz/ branch within
~15 seconds. If you want the replication window to be shorter,
set the replicationDelay within the remote block.

Internal developers will need to periodically merge the changes
from the dmz/* branches into one of the internal branches that the
internal developers actually use. This may or may not be annoying
to your team, it depends on the attitude they take to it.

A downside to this approach is your corporate firewall needs to allow
connections from the DMZ to the campus server. Usually this isn't
an accepted configuration by network security gurus. At least its
only port 29418 that has to be opened between the two hosts, vs.
say port 22, so there is more limited exposure.


The other approach is to *not* replicate from DMZ to campus, but
instead go the other direction, campus to DMZ.

Strongly encourage the external users to enable the commit-msg
hook so external changes have Change-Id footers in every change.
Disable Submit +1 on all projects on the DMZ host, so nobody can
submit a change there.

When a developer decides a change from an external party is good
enough for inclusion, they download it to their local workstation
and cherry-pick it into the current work branch, then upload it to
the campus server for review and submit.

The campus server than has a replication config like I explained
above, its just the reverse setup (dmz has a campus-host user with
push access) and the campus server replicates the change to the DMZ.
When the cherry-pick gets seen by the DMZ server its matched up
to the original change via the Change-Id footer, and the original
change is marked as Merged.

The downside to this approach is any branches replicated from the
internal campus server to the DMZ are visible on the DMZ almost
immediately. So you might need to use replication.config to limit
the list of branches which are pushed to a small subset of "public"
branches, while other branches are not replicated to the DMZ and
therefore are private.

It also requires your team to cherry-pick each commit they want to
include from the DMZ. As opposed to just doing a periodic merge
from dmz/master to master.


The only other best practice notes I have for Gerrit is:

- Give it a lot of RAM. For Android, if you can afford it, give
Gerrit's JVM 8 GiB of heap memory (-Xmx8g), and give the JGit
buffer cache a lot of memory (core.packedGitLimit = 2g) and a
lot of file descriptors (core.packedGitOpenFiles = 2048).

- Use local disk for the Git repositories.

- Run behind an Apache 2 server. Have Gerrit listen on
localhost:8081 and use mod_http_proxy in the Apache server to
forward requests received on the standard http/https ports to
the local Gerrit. This allows you to shift the SSL processing
from Java down into optimized C code.

- Use SSL for your HTTP access. *Especially* if you are using
OpenID or straight LDAP for authentication.

> Not sure if this is the right forum for this type of question.

It is. :-)