Upgrading and Operating a Secured Deployment

16 Upgrading and Operating a Secured Deployment

Coordinate artifacts, identities, configuration, diagnostics, and recovery across secured members and clients.

Security adoption is an application and operational rollout. Keep a recorded set of configuration, artifact, native-library, client, and credential versions. Use Rolling Upgrade to Hardened Security for the profile change and Assembling Secure Deployment Recipes for the combined service configuration.

Observe the boundary that makes the decision: transport, token assertion, class materialization, executable installation, operation authorization, resource limit, or stored/imported input. Security Errors and Diagnostic Signals maps the principal signals to corrective actions. Prefer a narrow fix to the producing artifact, identity mapping, or configuration over a global relaxation.

Routine operation

Rotate certificates and credentials with their actual provider/channel lifecycle and verify fresh connections.
Recheck policy after adding a service, client language, module, application class, native binary, or persisted subscriber definition.
Protect diagnostic artifacts and report output. Keep bounded logs and request IDs without sensitive payloads.
Exercise backup restoration and startup under the intended policy in an isolated environment.
Measure authorization and policy overhead with representative load and failure behavior, including credential-service outages.

Rolling Upgrade to Hardened Security
Prepare for the hardened default before upgrading, using an explicitly selected compatibility phase only where the migration plan requires one.
Assembling Secure Deployment Recipes
Combine the shared TLS, identity, authorization, and application-policy recipes into complete service deployments.

Rolling Upgrade to Hardened Security

Prepare for the hardened default before upgrading, using an explicitly selected compatibility phase only where the migration plan requires one.

Preparation

Inventory each client/member, enabled listener, serializer, remote executable family, configured identity/authorization chain, persistence/transaction workflow, and administrative tool. Record explicit settings as well as defaults. Include scrapers, health administration, Reporter schedules, JMX discovery, optional RAG imports, and native HNSW binaries.

Starting with Coherence 26.1.0.0, an unset coherence.security.mode selects hardened from the first startup. Validate the application and service policies before that startup. If an older deployment needs a temporary compatibility phase, explicitly set coherence.security.mode=compatibility on the affected upgraded processes before starting them. Preserve a deliberately hardened deployment. The runtime coherence.mode=prod setting remains independent of this choice.

Stage the application and service policies

A 26.1 Java client using compute or replaceAll against 14.1.2 or 15.1.1 servers must explicitly select coherence.security.mode=compatibility on the client before Coherence initializes. The hardened client can select newer named processors that those older servers do not recognize. Verify the supported client/server and serializer combinations; client interoperability and the profile of upgraded 26.1 servers are separate deployment settings.

Generate and deploy per-artifact security configuration for serialized types, remote executables, and custom lambda targets. Verify the receiving classloader sees every required resource.
If a temporary compatibility phase is selected, exercise real workflows with coherence.security.mode=compatibility explicitly configured. Review executable would_reject signals and separate management/Reporter/JMX warnings. These are incomplete readiness evidence; they do not inventory every accepted class or prove lambda/decoder readiness.
In an isolated environment, run the same client/server workloads with hardened policy. Set coherence.remote.dynamic.unauthenticated=deny explicitly if remote dynamic code is outside the deployment policy; the current integration default remains allow in either profile. Include legitimate largest payloads, denied operations, failover/reconnection, and replay/recovery.
Configure TLS, supported identity assertion, storage/service authorization, endpoint credentials, query/JSON aliases, finite serializer limits, approved Reporter paths, and static JMX publication as needed.
Coordinate credentials and clients before changing endpoint defaults. Verify metrics scraping, management tooling, and health administration on every relevant member.

Mixed-version data and capabilities

Transaction result/XID bridges retain their documented narrow type universes in both profiles. Drain or test custom XA XIDs before crossing the tightened bridge. A new transaction-binding reader uses typed fields and treats a legacy-only binding map as empty. Do not send binding-dependent traffic across that boundary without a coordinated plan.

Persisted topic subscriber metadata is rechecked on replay. Hardened policy defaults to rejection of executable-policy drift; warn-allow is an explicit migration bridge, not proof that the stored definition is still approved. Keep the defining classes and generated policy available on recovery readers.

Proof-required subject/senior workflows have physical-recipient and capability prerequisites beyond an ordinary patch rolling upgrade. Use Configuring Peer Proof Prerequisites and do not require proof merely because one member is ready.

Activation and recovery

Validate hardened behavior before the first 26.1.0.0-or-later startup unless a temporary compatibility phase has been explicitly selected. To finish that phase, remove coherence.security.mode=compatibility or set hardened explicitly after preparing the required members and clients. Keep consistent profiles for processes serving the same endpoint, and verify both success and intended refusals at each stage.

Prepare rollback before activation: configuration, application artifacts, credential overlap, data compatibility, and explicitly required independent policies. Returning to compatibility does not bypass built-in deny rules, malformed-input checks, explicit finite limits, health-mutator authentication, bridge filters, or explicitly required senior proof. A runtime mode change is not a security rollback.

Parent topic: Upgrading and Operating a Secured Deployment

Assembling Secure Deployment Recipes

Combine the shared TLS, identity, authorization, and application-policy recipes into complete service deployments.

A secured accounts cache with Extend

Create the protected TLS material and operational socket/password providers from Configuring TLS with Protected Password Sources. Configure the server JAAS identity asserter, protected JAAS file, and login-module dependencies from Authenticating Credentials with JAAS. Register accounts-policy using Implementing an Account Storage Authorizer. Merge these sections into one operational override in schema order.

The following complete server cache configuration exposes only the intended cache mapping and an mTLS Extend proxy. The named server-tls provider and accounts-policy declaration must already exist in that server's operational context.

<cache-config xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config">
  <caching-scheme-mapping>
    <cache-mapping>
      <cache-name>accounts</cache-name>
      <scheme-name>accounts-store</scheme-name>
    </cache-mapping>
  </caching-scheme-mapping>
  <caching-schemes>
    <distributed-scheme>
      <scheme-name>accounts-store</scheme-name>
      <service-name>AccountsService</service-name>
      <backing-map-scheme>
        <storage-authorizer>accounts-policy</storage-authorizer>
        <local-scheme/>
      </backing-map-scheme>
      <autostart>true</autostart>
    </distributed-scheme>
    <proxy-scheme>
      <scheme-name>accounts-proxy</scheme-name>
      <service-name>AccountsProxy</service-name>
      <acceptor-config>
        <tcp-acceptor>
          <socket-provider>server-tls</socket-provider>
          <address-provider>
            <local-address><address>0.0.0.0</address><port>20000</port></local-address>
          </address-provider>
        </tcp-acceptor>
      </acceptor-config>
      <autostart>true</autostart>
    </proxy-scheme>
  </caching-schemes>
</cache-config>

The client uses its own client-tls provider, the explicit credential transformer accepted by the server, and this cache configuration:

<cache-config xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config">
  <caching-scheme-mapping>
    <cache-mapping>
      <cache-name>accounts</cache-name>
      <scheme-name>accounts-client</scheme-name>
    </cache-mapping>
  </caching-scheme-mapping>
  <caching-schemes>
    <remote-cache-scheme>
      <scheme-name>accounts-client</scheme-name>
      <service-name>AccountsProxy</service-name>
      <initiator-config>
        <tcp-initiator>
          <socket-provider>client-tls</socket-provider>
          <remote-addresses>
            <socket-address><address>cache.example.com</address><port>20000</port></socket-address>
          </remote-addresses>
        </tcp-initiator>
      </initiator-config>
    </remote-cache-scheme>
  </caching-schemes>
</cache-config>

Use a unique cluster name for the isolated recipe deployment and choose the server/client operational and cache configuration files explicitly. Keep InvocationService and Concurrent proxies disabled unless the use case needs them. Package any custom payload/executable resources. With this mTLS example, every intended client must have a trusted client certificate as well as the configured application credential.

Verify writer success, reader read-only behavior, missing/invalid credentials, an untrusted/mismatched certificate, and a denied executable. Test reconnection and storage failover. These checks distinguish transport, identity, caller authorization, and executable policy.

An authenticated gRPC application

Use the same protected storage scheme and server identity setup with Configuring a Secure gRPC Proxy. Configure the product client with Connecting a Java gRPC Client Securely and the appropriate client cache mapping. Require transport on both sides, set diagnostic exposure explicitly, and approve only the intended serializer names. Verify the same authorized/denied operations through the actual gRPC protocol and client version.

Management, metrics, and health

Choose administrative/scraper identities, protected TLS providers, network placement, and explicit HTTP auth settings. Use Securing Management and Health Services and Configuring an Authenticated TLS Metrics Scrape. Leave health mutators disabled unless operationally required; if enabled, test their separate authentication without breaking read-only probes.

If JMXMP is enabled, use its authenticator, process-wide filter review, and provider-specific secure transport. If JMX/RMI discovery is used, configure static publication before hardened activation. Exercise the real JMX/Reporter schedules and monitoring tools in addition to HTTP reads.

Parent topic: Upgrading and Operating a Secured Deployment