rossoctl / rossoctl/operator

Fold bundle-service and token-broker into the operator image so they ship in releases

Open
#536 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement Identity
Dominant language
Go
Stars
18
Forks
50
Avg merge
3d 3h
Merged PRs (30d)
8

Description

Summary

The bundle-service (OPA authorization policy bundles, #415) and token-broker (OAuth session/token management, #449) are both merged and present in the source tree at v0.4.0-rc.1, but neither is deployable from the release artifacts. Both ship as standalone binaries with hand-written manifests that are not templated into the Helm chart and are not built or published by CI.

Net effect for a user installing rossoctl v0.8.0-rc.1: they get the authorizationpolicies CRD and the cortex-side opa/tokenbroker plugins that consume policy bundles, but no bundle-service and no token-broker running to serve them. Testing either feature currently requires building from source.

Resolution (agreed with @davidhadas): fold both binaries into the existing operator image. The components were originally split out to accommodate Red Hat objections; Red Hat is no longer consuming this as their upstream, so the split now only carries cost. Keeping them opt-out is also inconsistent with the rest of the codebase, which is opt-in. Goal is that testing a feature does not require a source build.

What was verified

Both PRs are merged to main and their merge commits are ancestors of the v0.4.0-rc.1 tag:

PR Merge commit In v0.4.0-rc.1
#415 Bundle Service serving OPA authorization policy bundles fb22549 yes
#449 Add token-broker service for OAuth session and token management 7887e96 yes

This is not a missing-code problem. It is a packaging and delivery gap.

Why documentation alone cannot fix this

The images do not exist. .github/workflows/release.yml builds exactly two images via its matrix — operator/Dockerfile and operator/cmd/agentcard-signer/Dockerfile. Neither component is included. The standalone manifests reflect that and cannot be applied as-is:

  • operator/config/bundleservice/deployment.yaml:23ghcr.io/rossoctl/bundle-service:latest, never built or pushed
  • token-broker/deploy/02-deployment.yaml:34localhost/token-broker:latest, with the inline comment "REPLACE with the tag your build script produces"

There is also no feature gate today: charts/operator/values.yaml at v0.4.0-rc.1 contains no reference to either component. The featureGates block covers globalEnabled, envoyProxy, injectTools, perWorkloadConfigResolution, and skillDiscovery only.

Component detail

bundle-service — already part of the github.com/rossoctl/operator module (operator/cmd/bundle-service/main.go), with supporting code in operator/internal/bundleservice/. The agent.rossoctl.dev_authorizationpolicies.yaml CRD is already shipped in charts/operator/crds/. Not registered as a reconciler in operator/cmd/main.go (it is a standalone HTTP server, not a controller). Manifests in operator/config/bundleservice/ are not templated into the chart.

token-broker — a separate Go module (github.com/rossoctl/token-broker) under token-broker/, depending on github.com/rossoctl/cortex/authbridge/authlib at pseudo-version v0.0.0-20260619001334-ce3417655ee8. Manifests in token-broker/deploy/ are not templated into the chart.

Cortex side is already correct

The consuming plugins are shipped. include_plugin_opa and include_plugin_tokenbroker are gated build tags, and both opa and tokenbroker are members of the full, envoy, and cpex profiles in authbridge/scripts/profile-tags/profiles.go. Published authbridge images have them compiled in; only -lite excludes them. This confirms the gap is operator-side packaging only.

Work items

  1. Fold bundle-service into the operator image. Add COPY cmd/bundle-service/ and a second go build stage to operator/Dockerfile, emitting a bundle-service binary alongside manager. Same module, so no dependency work required.

  2. Fold token-broker into the operator image. This requires merging module github.com/rossoctl/token-broker into github.com/rossoctl/operator first:

    • The operator module will inherit a dependency on cortex/authbridge/authlib, introducing a cross-repo build edge from operator to cortex. Confirm this is acceptable.
    • The existing authlib pin (v0.0.0-20260619..., June) is roughly three months stale against cortex v0.7.0-rc.1. It must be reconciled during the merge, and any authlib API drift resolved. This is the main unknown in the estimate — worth timeboxing before committing to a release.
    • Suggest doing this as its own PR ahead of the Dockerfile change, so module surgery is reviewable separately from packaging.
  3. Set explicit command: in both deployments. The operator image's ENTRYPOINT is ["/manager"] on distroless. With multiple binaries in one image, each Deployment must specify its own command: to select the right one.

  4. Template both into the Helm chart. Port operator/config/bundleservice/ and token-broker/deploy/ into charts/operator/templates/, each behind an opt-in values.yaml gate (suggest bundleService.enabled and tokenBroker.enabled, defaulting to false) to match the codebase's opt-in convention. Update image references to the operator image with the appropriate command:.

  5. Wire toggles through the rossoctl platform chart so the installer can enable them.

  6. Add an E2E smoke test that applies an AuthorizationPolicy and asserts bundle-service serves the composed bundle.

  7. Update documentation. Once installable from the chart, revise rossoctl#2139 — its manual pre-release instructions become obsolete.

Notes

  • Verification of published images was indirect: the token used had no read:packages scope, so GHCR could not be queried directly. The absence of both components from the release.yml build matrix is strong evidence, but a direct registry check would confirm it.
  • Release scoping for v0.8.0 GA vs the following release is open — /cc @cwiklik (build owner for v0.8.0). Item 2's stale authlib pin is the main schedule risk; items 1, 3, and 4 for bundle-service alone are small and low-risk.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with .github/workflows/release.yml, operator/Dockerfile, the bundle-service manifests under operator/config/bundleservice/, and token-broker/deploy/. Review the separate Go modules and authlib pin before planning the merge, then inspect charts/operator/templates/ and values.yaml. Done means both services can be enabled through the platform chart, run from the operator image, pass the requested E2E smoke test, and have updated documentation.

Written by the indexing model from the issue text.

Assessment

Tech stack
dockerfile, go, kubernetes
Domain
build-system, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.