Is it possible to add versions for new releases?

[dkulchinsky]

Hello folks!

Great project, thank you for your work 😄

We're currently evaluating it and so far quite happy with it, but one small item is a concern - it seems like any new release gets pushed to the latest tag and it's a bit difficult to track what is the current version and what was changed, we also need to have a predictable deployment and test changes in different pre-production environments before we can roll anything new.

Would it be possible to tag each release with a version tag?

[mlbiam]

Great project, thank you for your work

Thanks!

it seems like any new release gets pushed to the latest tag

Yes, we do this to make sure we're keeping up-to-date on both OS and package dependencies. Each of our containers is scanned daily to see if known CVEs have been patched on Ubuntu or Red Hat UBI, and if so the container is re-built. Furthermore, each release we rely on both snyk.io and maven's built in dependency management to make sure we have integrated the latest patched dependencies with the goal of having known vulnerabilities at "0" on each release. To make sure we haven't broken existing functionality, we have over 1,000 automated integration tests that we run (these aren't open source). For instance we maintain a keycloak server to test oidc and run our tests against it. We also maintain apache with mod_auth_oidc, asp.net with oidc and multiple k8s clusters for testing our oidc identity provider. It doesn't catch everything, but even our largest enterprise customers are running our latest build.

Since authentication is so core to security, we don't want to be in a position where a stale image is used that has a known vulnerability that's been patched is responsible for a breach. We work very hard to make it as easy as possible to use the latest version with confidence.

it's a bit difficult to track what is the current version and what was changed

Each Orchestra release is tied to it's corresponding OpenUnison release. You can see what's changed in each OpenUnison release - https://github.com/TremoloSecurity/OpenUnison/releases/. All of our commits are tied to issues to make it easier to track

we also need to have a predictable deployment and test changes in different pre-production environments before we can roll anything new.

Understood. We do have customers that want to ensure they're running on a specific version. These customers generally run they're own builds in they're CI/CD systems and use they're own scanning infrastructure to update on a patched CVE. Orchestra is very easy to build. You'll see in this repo is a GitHub actions build definition. I also have pipelines for Amazon CodeBuild, Jenkins, and Azure DevOps if you're interested. You can maintain a fork of this repo and as new versions become available, pull them in and rebuild.

Would it be possible to tag each release with a version tag?

We have considered this. The issue we run into is we don't maintain an "LTS" version and don't want to be in a situation where moving from 1.0.19 to 1.0.20 customers builds fail because we pulled down an older version.

We understand that many enterprises have policies around version management and are open to ideas as to how to better accommodate these policies.

[dkulchinsky]

Hey @mlbiam 😄

Thanks a lot for the detailed reply, I appreciate you taking the time to respond.

The effort around ensuring any new vuln gets patched and pushed asap is great, but not all changes are sec patching by nature, there could be functional changes as well, some may break things unexpectedly and that could be ok for a testing/staging/sandbox environment but is a concern for production environments.

This gets emphasized by various regulation and compliance requirements we (and probably others) may operate under, where changes in production must go a review and approval process, having the system pull a new version just because the upstream image tag was overwritten would break that control.

I agree, we could build the images ourselves in our CI and that would probably have to be the way to go for us, just thought that it might be a good idea to consider tagging release/version as I'd say it is a very common/best practice and in general latest tag is discouraged for various reasons (e.g. https://vsupalov.com/docker-latest-tag/, also K8s docs talk about it).

A specific technical concern in K8s is the use of notIfPresent pull image policy which is the default and most commonly used, in this case an updated image will never get pulled if the same tag already exist locally, so this would actually prevent in some situations from using the current(latest) release, or make things unpredictable (different nodes may run different version of the latest tag).

Perhaps a compromise (which I also see a lot of other projects use) is to have both 😉 by that I mean that you keep the latest tag which follows your repo's HEAD as today and additionally create version tags (could be dates, cloud be any other scheme).

This would allow us and others to choose the method that makes more sense considering various internal requirements.

In any case, thanks for hearing me out :-) this is of course just one opinion and as you suggested there's a reasonable alternative we can follow (i.e. building the images ourselves).

Cheers! and have a great weekend.