BREAKING CHANGE: the controller container is now executed under 65534:65534 (userid:groupid). This change may break deployments that hard-coded the user name 'controller' in their PodSecurityPolicy.
Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>
Further restricts the SecurityContext that the controller runs under, by enabling the default seccomp profile and dropping all linux capabilities.
This was set at container-level to ensure backwards compatibility with
use cases in which sidecars are injected into the source-controller pod
without setting less restrictive settings.
BREAKING CHANGE: The use of new seccomp API requires Kubernetes 1.19.
Co-authored-by: Sanskar Jaiswal <sanskar.jaiswal@weave.works>
Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>
Leverage libraries installed in base-debian11 (glibc, libssl and openssl)
therefore refrain from linking libc/libdl and ignore unresolved symbols
at build time.
Libssl had to be kept as the behaviour without it is not consistent across
all supported architectures.
Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>
The statically linked binary has lingering dependencing to glibc, which
leads to errors at runtime when using distroless/static. One key culprit is libnss,
which is not available in static form through package managers.
In order to support distroless/static, glibc would have to be recompiled using
the --enable-static-nss flag, and the resulting libnss_{dns,files}.a would need
to be linked during the build process.
Due to the unnecessary complexity mentioned above, distroless/base is being used
instead.
Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>
Adds an initial ATTRIBUTIONS.md file containing the open source
components that source-controller depends on, and their copyright
information.
Signed-off-by: Paulo Gomes <paulo.gomes@weave.works>
This moves the `libgit2` compilation to the image, to ensure it
can be build on builders that aren't backed by AMD64.
The image is structured in such a way that e.g. running nightly
builds targeting a different Go version, or targeting a different
OS vendor would be possible in the future via build arguments.
Signed-off-by: Hidde Beydals <hello@hidde.co>
To provide a better (contributing) experience to those with Apple
machines, as determining the correct paths there is a bit harder.
Signed-off-by: Hidde Beydals <hello@hidde.co>
To allow building a multi-platform container image using `buildx`.
Various configuration flags allow for fine(r)-grain control over the
build process:
- `BASE_IMG`: FQDN of the base image that should be used, without a
tag.
- `BASE_TAG: tag of the base image that should be used. Allows checksum
sum to be included.
- `BUILDX_PLATFORMS`: platforms to target for the final container
image.
- `BUILDX_ARGS`: additional `docker buildx build` arguments, e.g.
`--push` to push the result to a (local) image registry.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit updates `github.com/libgit2/git2go` to `v31.6.1` (with
`libgit2` `1.1.1`), and changes the container image build process so
that it makes use of `ghcr.io/hiddeco/golang-with-libgit2`.
This image provides a pre-build dynamic `libgit2` dependency linked
against OpenSSL and LibSSH2 (without gcrypt), and a set of cross-compile
build tools (see
[rationale](https://github.com/hiddeco/golang-with-libgit2#rationale) and
[usage](https://github.co/hiddeco/golang-with-libgit2#usage) for more
detailed information).
The linked set of dependency should solve most known issues around
unsupport private key types, but does not resolve the issues with ECDSA*
and ED25519 hostkeys yet. Solving this requires a newer version of
`libgit2` (`>=1.2.0`), which currently does not seem to work properly
with `git2go/v32`.
Some small changes have been made to the `libgit2` package to address
(future) deprecations.
Signed-off-by: Hidde Beydals <hello@hidde.co>
We received reports from users no longer being able to clone Git
repositories using libgit2 because of errors during the cloning
attempt: `error: Failed to authenticate SSH session: Unable to extract
public key from private key.`
After an extensive scavenger hunt I was able to pinpoint the issue to
`libssh2` being linked against `libgcrypt` instead of `openssl`. The
problem with this is that the libgcrypt backend in libssh2 contains
a hand written slimmed down ASN.1 parser to read out keys, while the
OpenSSL backend in libssh2 uses OpenSSL, which supports a lot more
formats (and more specifically, most PKCS* formats).
As Debian's bullseye/testing repository has been frozen, and a
backport has not been made available yet, fetching the dependency from
"unstable" seems to be the best option for now, as this has `libssh2`
available including OpenSSL.
Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668271
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit changes the base image for the build and controller
container images to Debian slim.
Reason for this is that it has proven to be hard to produce working
executables for AMD64, ARM64 and ARMv7 at all times using Alpine,
due to them being dynamically linked and compiled using CGO, and
Alpine having constraints like musl that create an extra barrier,
especially in combination with our exotic set of dependency
constraints.
There are a number of trade-offs we have to live with by doing this,
not limited to:
* An increased build time, the full release pipeline used to take 25-35
minutes, based on the images we have build for testing purposes this
seems to have become 35-40 minutes.
* An increased image size of roughly two times the (compressed) size of
the Alpine based image.
Signed-off-by: Hidde Beydals <hello@hidde.co>
There seems to have been a change in the dependencies that now causes
ARMv7 builds to fail:
```
sigs.k8s.io/kustomize/kyaml/yaml/merge3=$WORK/b742/_pkg_.a
sigs.k8s.io/kustomize/kyaml/yaml/internal/k8sgen/pkg/util/errors=$WORK/b678/_pkg_.a
-importcfg $WORK/b001/importcfg.link -buildmode=exe
-buildid=YHfd11eGufJ7RVGSGz2z/H9JgY3lbjsdhQ8_r06Gz/HiYQEtSgCAIHJ7rrNYN6/YHfd11eGufJ7RVGSGz2z
-extld=gcc $WORK/b001/_pkg_.a
exit status 1
-c CGO_ENABLED=1 go build -x -o source-controller main.go]: exit
code: 2
```
After trying various things, including downgrading Go, using
packages from `edge`, using `gcc-go` to get a "grouped" version of
the dependencies, it seems that using `binutils-gold` solves the issue
and produces a working build for all our target architectures.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit updates Go to 1.16, a required change because of the use of
`os.WriteFile` in one of the tests introduced by commit
b5004a93bc.
Normally _just_ this would not justify the change, but given the
introduction of breaking changes (and thereby forcing a MINOR update
anyway), and the various file{system, path} improvements introduced in
Go 1.16 like
[`filepath#WalkDir`](https://golang.org/pkg/path/filepath/#WalkDir),
going ahead with this should be fine.
Signed-off-by: Hidde Beydals <hello@hidde.co>
* Use semver tidles to deal with future patch releases
* Install just `libgit2` in runtime container
* Add TODO / explanation for `musl` `1.2.x` dependency
Signed-off-by: Hidde Beydals <hello@hidde.co>
As other controllers depend on source-controller because of the API
package, but this pulls in obsolete dependencies for the controllers.
By publishing the API package as a dedicated module while
using a (local) replace for the project itself, this should be
prevented.
Paulo Gomes
Stefan Prodan
Aurel Canciu
Hidde Beydals
Philip Laine
Philip Laine