[SERVER-55273] ReplSetTest and ShardingTest objects does not support x509 authentication Created: 17/Mar/21  Updated: 06/Dec/22  Resolved: 04/May/21

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File test_x509.js    
Issue Links:
Depends
is depended on by SERVER-55824 Make ssl_get_more.js start shards as ... Closed
Related
related to SERVER-14017 Refactor ShardingTest and ReplSetTest... Backlog
is related to SERVER-53605 Ensure replsettest.asCluster works wi... Closed
is related to SERVER-43899 Blacklist sharding_with_x509.js and s... Closed
Assigned Teams:
Replication
Operating System: ALL
Steps To Reproduce:

1. Run the attached script with on the ssl suite.

Participants:

 Description   

The following snippet results in a JavaScript error when initializing a cluster:

'use strict';
 
var x509_options = {
    sslMode: "requireSSL",
    sslPEMKeyFile: "jstests/libs/server.pem",
    sslCAFile: "jstests/libs/ca.pem",
    sslClusterFile: "jstests/libs/cluster_cert.pem",
    sslAllowInvalidHostnames: "",
    clusterAuthMode: "x509"
};
 
var st = new ShardingTest({
    shards: 2,
    mongos: 1,
    other: {
        enableBalancer: true,
        configOptions: x509_options,
        mongosOptions: x509_options,
        rsOptions: x509_options,
        shardOptions: x509_options
    }
});
 
st.stop();

With the following backtrace:

assert: command failed: {
	"ok" : 0,
	"errmsg" : "not authorized on admin to execute command { serverStatus: 1.0, lsid: { id: UUID(\"aeb11c69-c642-4f3b-8910-915161999c85\") }, $db: \"admin\" }",
	"code" : 13,
	"codeName" : "Unauthorized"
} with original command request: {
	"serverStatus" : 1,
	"lsid" : {
		"id" : UUID("aeb11c69-c642-4f3b-8910-915161999c85")
	}
} on connection: connection to ip-10-122-78-134.ec2.internal:20520
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:719:17
assert.commandWorked@src/mongo/shell/assert.js:811:16
_isRunningWithoutJournaling/result<@src/mongo/shell/replsettest.js:214:32
asCluster@src/mongo/shell/replsettest.js:203:20
_isRunningWithoutJournaling@src/mongo/shell/replsettest.js:213:22
ReplSetTest/this._updateConfigIfNotDurable@src/mongo/shell/replsettest.js:1167:13
ReplSetTest/this._setDefaultConfigOptions@src/mongo/shell/replsettest.js:1176:9
ReplSetTest/this.initiateWithAnyNodeAsPrimary@src/mongo/shell/replsettest.js:1318:9
initiateReplicaSet@src/mongo/shell/shardingtest.js:1634:9
ShardingTest@src/mongo/shell/shardingtest.js:1709:13
@jstests/ssl/sharding_with_x509.js:20:10
@jstests/ssl/sharding_with_x509.js:3:2

The cause of this seems to be that when initializing a shard as a replica set a server status command is being executed but the only authentication method available is by using a keyFile, so there is no way of using x509. There is an old ticket proposing a refactor of ShardingTest and ReplSetTest. Until this is fixed, tests like sharding_with_x509.js or speculative-auth-sharding.js must be blacklisted.



 Comments   
Comment by Mark Benvenuto [ 04/May/21 ]

Yeah, I think we can close it. Note, that in order to ensure x509 auth works correctly, you need to have a suite configuration that starts the shell with the same certificate as the cluster cert (typically server.pem).

Comment by Tommaso Tocci [ 04/May/21 ]

mark.benvenuto  should we close this as duplicated of SERVER-53605 since it has been fixed recently ?

Generated at Thu Feb 08 05:36:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.