Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:38:22 +0000.
Sender:[email protected]
.
Date:Tuesday, 22 December 2015 15:00:05 UTC.
Hi,
We may be attempting the impossible here, or, more likely, I’m mis-conffiguring something, but we’re trying to secure access to our MongoDB instances through role-based access controls and we’re running into some problems with Tyk accessing MongoDB.
We run three MongoDB instances as a replica set, and without any access control applied to MongoDB then Tyk behaves just fine. When we enable role-based access control on MongoDB then tyk fails to connect with an “Mongo connection failed:auth failed” message.
At the MongoDB end I’ve created a user named ‘tyk’ for the tyk_analytics database with a password of ‘tok’ (say) and the role of dbOwner. Using the mongo client I can access the database as this user and authenticate. When I configure the mongo_url parameter in tyk.conf as:
“mongo_url”: “mongodb://tyk:[email protected]:27017/tyk_analytics”
then we get the following error message repeatedly:
tyk: time=“2015-12-22T14:15:00Z” level=error msg=“Mongo connection failed:auth failed”
The tyk-mongo.service.consul address is because we’re using Hashicorp’s Consul as a service discovery mechanism which effectively resolves tyk-mongo.service.consul to one of three MongoDB instances in a round-robin fashion.
Some more detail. The whole tyk.conf file looks like this:
{
“listen_port”: 5000,
“secret”: “njRiQMcdWEbHaj5PoaUvCLXnTOeL4P14”,
“template_path”: “/etc/tyk/templates”,
“tyk_js_path”: “/etc/tyk/js/tyk.js”,
“use_db_app_configs”: true,
“app_path”: “/etc/tyk/apps”,
“middleware_path”: “/etc/tyk/middleware”,
“enable_analytics”: true,
“analytics_config”: {
“type”: “mongo”,
“csv_dir”: “/tmp”,
“mongo_url”: “mongodb://tyk:[email protected]/tyk_analytics”,
“mongo_db_name”: “tyk_analytics”,
“mongo_collection”: “tyk_analytics”,
“purge_delay”: 10,
“ignored_ips”: []
},
“storage”: {
“type”: “redis”,
“host”: “redis-master.service.consul”,
“port”: 6379,
“username”: “”,
“password”: “”,
“database”: 0,
“optimisation_max_idle”: 100
},
“health_check”: {
“enable_health_checks”: true,
“health_check_value_timeouts”: 60
},
“optimisations_use_async_session_write”: true,
“allow_master_keys”: true,
“policies”: {
“policy_source”: “mongo”,
“policy_record_name”: “tyk_policies”
},
“hash_keys”: false,
“suppress_redis_signal_reload”: false
}
Running service tyk status gives:
Redirecting to /bin/systemctl status tyk.service
tyk.service - tyk
Loaded: loaded (/etc/systemd/system/tyk.service; enabled)
Active: active (running) since Tue 2015-12-22 14:07:55 GMT; 24min ago
Main PID: 2665 (tyk)
CGroup: /system.slice/tyk.service
└─2665 /etc/tyk/tyk
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
Dec 22 14:32:30 tyk-gateway-i-6e3d56e3 tyk[2665]: time=“2015-12-22T14:32:30Z” level=error msg=“Mongo connection failed:auth failed”
I hope that’s enough information for someone to point us in the right direction.
Many thanks,
–
Trevor Marshall