Hello,
We are gearing up to rolling out the Cloud DDC for our studio, however an InfoSec requirement we have is that the Scylla DB must has authentication enabled (regardless of how it’s used). I see that there are no options for enabling this, although I see in the implementation of the ‘ScyllaFactory’ function we can enable this through the Cluster Builder. Is this something that can be added for a future version?
Thanks,
William
Hey William
You should be able to pass the authentication into the connection string using the username and password fields. We do not use this and thus haven’t tested it but I know some teams that tried managed cassandra databases (before giving up and going to Scylla) and this seemed to cover the authentication needs they had.
See CassandraConnectionStringBuilder Class for some docs on what can be in the connection string, its a bit bare bones and hard to find, I usually fallback to reading the code but in terms of auth I think a basic username and password should be no problem. I have no idea if or how you could connect that to something else if that was a requirement.
If the connection string path is not enough I am happy to add a explicit username and password that can be appended by the code into the connection builder if needed, if so just reopen this and let me know.
Hi Joakim,
So the other issue with the error code 400s was happening due to the scylla authentication that I put in place, what I did was apply the PasswordAuthenticator type on the scylla node, I configured the users so we have our own user and dropped the default cassandra user. Then on the cloud ddc side I have tried to apply the user/password into the ConnectionString of the values like so
ConnectionString: “Contact Points=<ScyllaNode>;Default Keyspace=jupiter;Username=<ScyllaUser>;Password=<ScyllaPassword>”
But it doesn’t seem to get applied, I noticed that once the ‘cassandra’ user is dropped then the above errors will start (pretty much immediately afterwards). I’ve tried restarting the pods after applying the updated values but to no difference, strangely the logs don’t complain about not being able to connect to scylla (so my credentials are being used somewhere I presume), but my guess is it’s still trying to use the default credentials somewhere.
Perhaps if this was more explicit in the connection builder that might help?
Being more explicit may help but it if the credentials are being picked up already (which they should) then its likely something else.
It might be best to make sure that you can actually do write operations against Cloud DDC after the pod has restarted, usually doing something like this from Powershell
`curl https://<your-url>/api/v1/refs/ue.ddc/default/00000000000000000000000000000000000000aa -X PUT --data “new-test-data-2” -H “content-type: application/octet-stream” -H “X-Jupiter-IoHash: C8C0E174B539F9EBAC3FA8B937B7CF74A81EF11B” -i -H $env:curl_auth_header`
The header can be injected using the script at ./Engine/Source/Programs/UnrealCloudDDC/updateAuthHeaderUser.ps1
So in powershell these two commands
`. Engine/Source/Programs/UnrealCloudDDC/updateAuthHeaderUser.ps1 (triggers interactive login)`
`curl https://<your-url>/api/v1/refs/ue.ddc/default/00000000000000000000000000000000000000aa -X PUT --data “new-test-data-2” -H “content-type: application/octet-stream” -H “X-Jupiter-IoHash: C8C0E174B539F9EBAC3FA8B937B7CF74A81EF11B” -i -H $env:curl_auth_header`
Should trigger a write operation and you can verify that its actually working as it should (based on the response)
It does make sense that you see the 400 results if the authentication isn’t working correctly.
Are you using a multiregion Scylla setup? Maybe the replicator factor or replication configuration for the system table isn’t setup correctly so the authentication is different between different scylla nodes, so only some of the request succeed and some fail?
Hi Joakim,
Due to issues with .Net versions (OidcToken portable seems to require .Net 6 which we can’t have due to security concerns) I couldn’t test manually putting data onto the Cloud DDC, however I did attempt once more to change to PasswordAuthenticator on the Scylla node and then I rebuilt the cluster, and that seems to have done the trick and it seems to be working with my credentials and without the default cassandra user. I’m confused as to why restarting the pods previously did not work, but it all seems OK now. Apologies for jumping the gun here!