Description
Up to this point, we were testing alternator without enforced authorization:
alternator_enforce_authorization: falseWe should test the enabled version instead, but it looks like SM does not handle this case well.
Simply enforcing authorization results in:
=== RUN TestPingIntegration/query
dynamoping_integration_test.go:34: MissingAuthenticationTokenException: Authorization header is mandatory
Here is the dynamodb config used for pinging alternator:
// Config specifies the ping configuration, note that timeout is mandatory and
// zero timeout will result in errors.
type Config struct {
Addr string
RequiresAuthentication bool
Username string
Password string
Timeout time.Duration
TLSConfig *tls.Config
}Even though it contains the Password and Username fields, they are never set.
The same goes for the RequiresAuthentication field.
They are only used here:
sess := session.Must(session.NewSessionWithOptions(session.Options{
Config: aws.Config{
Endpoint: aws.String(config.Addr),
Region: aws.String("scylla"),
HTTPClient: httpClient(config),
},
}))
if config.RequiresAuthentication && config.Username != "" && config.Password != "" {
sess.Config.Credentials = credentials.NewStaticCredentials(config.Username, config.Password, "")
} else {
sess.Config.Credentials = credentials.AnonymousCredentials
}Which means that we always use the anonymous credentials.
The problem here is not about simply setting Password, Username, RequiresAuthentication fields to known values.
According to alternator docs, the password used for authenticating alternator queries is not the CQL password, but rather its salted hash kept in system.roles table. This means that even when user specifies CQL credentials for the cluster, we are still missing the alternator password.
The short workaround would be to only use QueryPing when RequiresAuthentication = false.
The proper fix would be to add a new cluster fields --alternator-user, --alternator-password and use them for alternator healthcheck.
I was also thinking about SM retrieving the salted hash from Scylla itself when the CQL credentials are set (by querying the system.roles table), but this seems like something easy to break in the future. Not to say that SM might not have the right permissions to read from system.roles table in the first place.