Upgrade of standalone serviceFabric cluster with mixed security

Sebastian Tkocz 6 Reputation points
2020-08-05T12:27:14.487+00:00

Hi,

We have a test (3 nodes) and a prod ( 5 nodes) standalone service fabric clusters, version 7.0.470.9590
And we have a mixed security model, i.e. cluster security is Windows (AD group) and server security is X509 certificate.

The upgrade to 7.1.428 fails with an error:
System.Fabric.FabricDeployer.ClusterManifestValidationException: Cluster manifest validation failed with exception System.ArgumentException: Cluster and server credential types must match when either is set for X509; cluster: Windows, server: X509

But release notes for 7.1 CU2 states that:
Potential 7.1 Deployment Failures:
Cause: SF 7.1 introduced a more rigorous validation of security settings; in particular, requiring that settings ClusterCredentialType and ServerAuthCredentialType have matching values. However, existing clusters may have been created with 'x509' for the ServerAuthCredentialType and 'none' for the ClusterCredentialType.
Impact: In the case mentioned above, attempting an upgrade to SF71CU1 will cause the upgrade to fail.
Workaround: No workaround exists for this issue, as the ClusterCredentialType is immutable. If you are in this situation, please continue using SF70 until the 7.1 second refresh release becomes available.

But 7.1.428 is the second refresh for 7.1 right? Am I misunderstanding something?
Was it planned to be fixed in CU2 but it id not happen, or is there a typo in the description and it's going to be fixed in CU3?
Is the mixed security going to be supported or shall we drop the clusters and create new ones?

Sebastian

Azure Service Fabric
Azure Service Fabric
An Azure service that is used to develop microservices and orchestrate containers on Windows and Linux.
264 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. KarishmaTiwari-MSFT 20,037 Reputation points Microsoft Employee
    2020-08-11T22:08:15.27+00:00

    @Sebastian Tkocz

    I got the confirmation from the product team.

    Mixed-mode authentication has not been supported in SF, irrespective of what the cluster definition allowed. Any mismatch was simply an omission in setting validation – the actual authentication is really ‘either or’. The CU2 release notes refer to the case where the cluster credential type is set to ‘none’, which is the default value for that setting and was unfortunately allowed as a creation-time configuration.

    Prior to CU2, the security validation enforced (incorrectly) the starting (== current) state of the cluster at the beginning of an upgrade; this has been fixed and shipped with CU2. However, the enforcement on the ‘target’ cluster configuration is still in effect, and both credential types are expected to be x509.

    Note that, CU3 bring proper support for specifying a server certificate for the http gateway in Windows-authentication-based SF clusters.

    1 person found this answer helpful.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.