[
https://issues.apache.org/jira/browse/GEODE-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8353:
--------------------------------
Description:
We would like to protect developers building/rebuilding images from the
official Geode {{Dockerfile}} from inadvertently downloading/using inauthentic
software. The risk is that somehow a bad actor gains access to apache.org
servers and puts malicious software there.
The current approach to securing the {{Dockerfile}} for the official Geode
Docker image is to include the product SHA in the file. As a result, the source
code of the {{Dockerfile}} used to produce the official Docker image, for
publication on Docker Hub, is not part of the source code covered by the Geode
product SHA. This is known as the "chicken-and-egg" problem. Instead, the
{{Dockerfile}} comes from the {{master}} branch.
This presents a number of problems:
1. folks looking at the Geode source code do not see the correct {{Dockerfile}}
source unless they know to look for it on the {{master}} branch
2. the release process has extra steps to maintain the {{Dockerfile}} on the
master branch
3. inescapably, revisions to the the {{Dockerfile}} on the master branch follow
a linear progression whereas the sources of that file are following a
tree-structured one
4. it isn't possible to validate the product SHA the way you could a public
key. About all a developer can do is read the SHA from the {{Dockerfile}} and
compare it to a SHA on an apache.org site. But that depends on the security of
that apache.org site.
When this story is complete, Geode's official Docker image will not come from
the {{Dockerfile}} on the master branch. Instead, the {{Dockerfile}} on
{{develop}} and support branches, will contain the public key ID of the (a)
release manager instead of a product SHA. Verification will proceed like this
inside the {{Dockerfile}}:
1. download release manager's public key-cert from key server {{gpg --keyserver
some.apache.key.server --recv-keys release-managers-key-id-from-dockerfile}}
2. download product checksums
3. download a signature for the checksums—signed by the release manager's
private key
4. download product distribution
5. validate checksums (2) with signature (3) {{gpg --batch --verify
signature-file downloaded-checkums-file}}
6. verify that locally-computed product checksums match downloaded ones
If any of those steps fail, then the {{Dockerfile}} build fails.
This is similar to the approach used in these {{Dockerfile}}s:
* HashiCorp Consul: https://hub.docker.com/_/consul
* Apache Web Server httpd: https://hub.docker.com/_/httpd
The Apache httpd {{Dockerfile}} uses a slightly simpler approach than the
Consul one. They sign the release tarball directly instead of signing a
checksums file. That eliminates step (2). In (3) they download a signature of
the tarball. In (5) they validate the checksum directly against the tarball.
Release manager instructions will be updated to reflect these structural and
procedural changes.
Steps (2) and (3) may require additions to our release process. TBD if we
already have a checksums file (2). I don't think we have a signature (3) over
that file.
Some validation steps cannot be done inside the Dockerfile. One is validating
that the release manager's public key is trustworthy. (see _Validating
Authenticity of a Key_ here: https://www.apache.org/info/verification.html)
Ostensibly, the Geode community would ensure the validity of the public key ID
in the Dockerfile in the release branches of the public Git repo. Developers
using the {{Dockerfile}} could see the release managers public key ID and could
validate that.
As for validating Docker _images_ e.g. hosted on Docker Hub, that is out of
scope for this story.
was:
We would like to protect developers building/rebuilding images from the
official Geode {{Dockerfile}} from inadvertently downloading/using inauthentic
software. The risk is that somehow a bad actor gains access to apache.org
servers and puts malicious software there.
The current approach to securing the {{Dockerfile}} for the official Geode
Docker image is to include the product SHA in the file. As a result, the source
code of the {{Dockerfile}} used to produce the official Docker image, for
publication on Docker Hub, is not part of the source code covered by the Geode
product SHA. This is known as the "chicken-and-egg" problem. Instead, the
{{Dockerfile}} comes from the {{master}} branch.
This presents a number of problems:
1. folks looking at the Geode source code do not see the correct {{Dockerfile}}
source unless they know to look for it on the {{master}} branch
2. the release process has extra steps to maintain the {{Dockerfile}} on the
master branch
3. inescapably, revisions to the the {{Dockerfile}} on the master branch follow
a linear progression whereas the sources of that file are following a
tree-structured one
4. it isn't possible to validate the product SHA the way you could a public
key. About all a developer can do is read the SHA from the {{Dockerfile}} and
compare it to a SHA on an apache.org site. But that depends on the security of
that apache.org site.
When this story is complete, Geode's official Docker image will not come from
the {{Dockerfile}} on the master branch. Instead, the {{Dockerfile}} on
{{develop}} and support branches, will contain the public key ID of the (a)
release manager instead of a product SHA. Verification will proceed like this
inside the {{Dockerfile}}:
1. download release manager's public key-cert from key server {{gpg --keyserver
some.apache.key.server --recv-keys release-managers-key-id-from-dockerfile}}
2. download product checksums
3. download a signature for the checksums—signed by the release manager's
private key
4. download product distribution
5. validate checksums (2) with signature (3) {{gpg --batch --verify
signature-file downloaded-checkums-file}}
6. verify that locally-computed product checksums match downloaded ones
If any of those steps fail, then the {{Dockerfile}} build fails.
This is similar to the approach used in these {{Dockerfile}}s:
* HashiCorp Consul: https://hub.docker.com/_/consul
* Apache Web Server httpd: https://hub.docker.com/_/httpd
Release manager instructions will be updated to reflect these structural and
procedural changes.
Steps (2) and (3) may require additions to our release process. TBD if we
already have a checksums file (2). I don't think we have a signature (3) over
that file.
Some validation steps cannot be done inside the Dockerfile. One is validating
that the release manager's public key is trustworthy. (see _Validating
Authenticity of a Key_ here: https://www.apache.org/info/verification.html)
Ostensibly, the Geode community would ensure the validity of the public key ID
in the Dockerfile in the release branches of the public Git repo. Developers
using the {{Dockerfile}} could see the release managers public key ID and could
validate that.
As for validating Docker _images_ e.g. hosted on Docker Hub, that is out of
scope for this story.
> Replace Product SHA with Release Manager's Public Key ID in Dockerfile for
> Official Docker Image
> ------------------------------------------------------------------------------------------------
>
> Key: GEODE-8353
> URL: https://issues.apache.org/jira/browse/GEODE-8353
> Project: Geode
> Issue Type: Bug
> Reporter: Bill Burcham
> Priority: Major
>
> We would like to protect developers building/rebuilding images from the
> official Geode {{Dockerfile}} from inadvertently downloading/using
> inauthentic software. The risk is that somehow a bad actor gains access to
> apache.org servers and puts malicious software there.
> The current approach to securing the {{Dockerfile}} for the official Geode
> Docker image is to include the product SHA in the file. As a result, the
> source code of the {{Dockerfile}} used to produce the official Docker image,
> for publication on Docker Hub, is not part of the source code covered by the
> Geode product SHA. This is known as the "chicken-and-egg" problem. Instead,
> the {{Dockerfile}} comes from the {{master}} branch.
> This presents a number of problems:
> 1. folks looking at the Geode source code do not see the correct
> {{Dockerfile}} source unless they know to look for it on the {{master}} branch
> 2. the release process has extra steps to maintain the {{Dockerfile}} on the
> master branch
> 3. inescapably, revisions to the the {{Dockerfile}} on the master branch
> follow a linear progression whereas the sources of that file are following a
> tree-structured one
> 4. it isn't possible to validate the product SHA the way you could a public
> key. About all a developer can do is read the SHA from the {{Dockerfile}} and
> compare it to a SHA on an apache.org site. But that depends on the security
> of that apache.org site.
> When this story is complete, Geode's official Docker image will not come from
> the {{Dockerfile}} on the master branch. Instead, the {{Dockerfile}} on
> {{develop}} and support branches, will contain the public key ID of the (a)
> release manager instead of a product SHA. Verification will proceed like this
> inside the {{Dockerfile}}:
> 1. download release manager's public key-cert from key server {{gpg
> --keyserver some.apache.key.server --recv-keys
> release-managers-key-id-from-dockerfile}}
> 2. download product checksums
> 3. download a signature for the checksums—signed by the release manager's
> private key
> 4. download product distribution
> 5. validate checksums (2) with signature (3) {{gpg --batch --verify
> signature-file downloaded-checkums-file}}
> 6. verify that locally-computed product checksums match downloaded ones
> If any of those steps fail, then the {{Dockerfile}} build fails.
> This is similar to the approach used in these {{Dockerfile}}s:
> * HashiCorp Consul: https://hub.docker.com/_/consul
> * Apache Web Server httpd: https://hub.docker.com/_/httpd
> The Apache httpd {{Dockerfile}} uses a slightly simpler approach than the
> Consul one. They sign the release tarball directly instead of signing a
> checksums file. That eliminates step (2). In (3) they download a signature of
> the tarball. In (5) they validate the checksum directly against the tarball.
> Release manager instructions will be updated to reflect these structural and
> procedural changes.
> Steps (2) and (3) may require additions to our release process. TBD if we
> already have a checksums file (2). I don't think we have a signature (3) over
> that file.
> Some validation steps cannot be done inside the Dockerfile. One is validating
> that the release manager's public key is trustworthy. (see _Validating
> Authenticity of a Key_ here: https://www.apache.org/info/verification.html)
> Ostensibly, the Geode community would ensure the validity of the public key
> ID in the Dockerfile in the release branches of the public Git repo.
> Developers using the {{Dockerfile}} could see the release managers public key
> ID and could validate that.
> As for validating Docker _images_ e.g. hosted on Docker Hub, that is out of
> scope for this story.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
