Skip to content

Adding an option to ACS to use cluster CA, not self signed for ACS Central #131

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
p-rog wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Adding an option to ACS to use cluster CA, not self signed for ACS Central #131

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bd1089a
Adding an option to ACS to use cluster CA, not self signed, for ACS C…
p-rog May 8, 2026
479f2f7
Adding explanation how ACS handles two OCP routes
p-rog May 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions charts/acs-central/templates/central-cr.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,13 @@ spec:
port: 443
route:
enabled: {{ .Values.central.exposure.route.enabled }}
Copy link
Copy Markdown
Collaborator

@sabre1041 sabre1041 May 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If reencrypt is enabled, lets disable the default route

Copy link
Copy Markdown
Collaborator Author

@p-rog p-rog May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like I mentioned in the PR description, we have to keep the self-signed route because this is required for the communication between ACS Central and Sensors. Here is official ACS explanation:
https://access.redhat.com/solutions/7019861
and here is how it's coded:
https://github.com/stackrox/stackrox/blob/master/operator/api/v1alpha1/central_types.go#L458
The same is in the Central CRD manifest:

DESCRIPTION:
    Expose Central with a reencrypt route.
    Should not be used for sensor communication.
    The default is: false.

So if we disable passthrough and use only reencrypt (with the same hostname) it would break sensor communication.

{{- if .Values.central.exposure.route.reencrypt.enabled }}
reencrypt:
enabled: true
{{- if .Values.central.exposure.route.reencrypt.host }}
host: {{ .Values.central.exposure.route.reencrypt.host }}
Copy link
Copy Markdown
Collaborator

@sabre1041 sabre1041 May 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If reencrypt is enabled, lets set the value to the default central hostname (unless explicitly declared)

Copy link
Copy Markdown
Collaborator Author

@p-rog p-rog May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we have to keep the passthrough for the sensors communication, hence the reencrypt route needs its own, distinct hostname.

{{- end }}
{{- end }}

{{- if .Values.central.persistence.enabled }}
persistence:
Expand Down
4 changes: 4 additions & 0 deletions charts/acs-central/templates/console-link.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,11 @@ metadata:
annotations:
argocd.argoproj.io/sync-wave: "46"
spec:
{{- if .Values.central.exposure.route.reencrypt.enabled }}
href: https://central-reencrypt-{{ .Release.Namespace }}.{{ .Values.global.localClusterDomain }}
{{- else }}
href: https://central-{{ .Release.Namespace }}.{{ .Values.global.localClusterDomain }}
{{- end }}
location: ApplicationMenu
text: Advanced Cluster Security
applicationMenu:
Expand Down
2 changes: 1 addition & 1 deletion charts/acs-central/templates/jobs/create-auth-provider.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ spec:
exit 0
fi
ACS_CENTRAL_HOSTNAME="$(oc get route central -n stackrox -o jsonpath='{.spec.host}')"
ACS_CENTRAL_HOSTNAME="$(oc get route central-reencrypt -n stackrox -o jsonpath='{.spec.host}' 2>/dev/null || oc get route central -n stackrox -o jsonpath='{.spec.host}')"
echo "ACS Central hostname: $ACS_CENTRAL_HOSTNAME"
cat > /tmp/oidc-config.json << 'OIDCEOF'
Expand Down
3 changes: 2 additions & 1 deletion charts/acs-central/values.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,10 +73,11 @@ central:
exposure:
route:
enabled: true
# Use cluster wildcard certificate
tls:
enabled: true
termination: passthrough
reencrypt:
enabled: true
loadBalancer:
enabled: false

Expand Down
28 changes: 28 additions & 0 deletions docs/acs-deployment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,34 @@ The ACS deployment in the Layered Zero Trust pattern is implemented using:
- Admission Controller (policy enforcement)
- Collector (DaemonSet for runtime monitoring)

## Route and TLS Configuration

ACS Central exposes two OpenShift routes with different TLS termination modes:

| Route | TLS Mode | Purpose |
|---|---|---|
| `central` | Passthrough | Sensor/SecuredCluster gRPC communication (mTLS) |
| `central-reencrypt` | Reencrypt | Browser UI access using cluster wildcard certificate |

The **passthrough route is required** for sensor communication. Sensors use
mutual TLS with certificates from the cluster init bundle, and the RHACS
operator [explicitly states](https://github.com/stackrox/stackrox/blob/master/operator/api/v1alpha1/central_types.go)
that the reencrypt route *"should not be used for sensor communication"*
because the router terminates the sensor's TLS session, breaking mTLS
authentication.

The **reencrypt route** is enabled by default (`central.exposure.route.reencrypt.enabled: true`)
so that browser users see the cluster's wildcard certificate instead of
Central's self-signed certificate. This works on all platforms:

- **Cloud (AWS, Azure, GCP)**: wildcard cert is signed by a public CA — no browser warning
- **BareMetal / vSphere**: wildcard cert uses the cluster ingress CA — trusted
if `ztvp-certificates` has injected it via `proxyCA`

The RHACS operator auto-generates the reencrypt route hostname
(`central-reencrypt-stackrox.apps.<domain>`). The ConsoleLink and OIDC auth
provider `uiEndpoint` automatically point to the reencrypt route when enabled.

## Deployment Workflow

### Phase 1: Operator Installation (Managed by Pattern Framework)
Expand Down
Loading