Page MenuHomePhabricator

Investigate how automated tasks can authenticate against CAS
Closed, ResolvedPublic

Description

We have some automated tasks which will need to authenticate to services via CAS. for instance the meta-monitoring scripts need access to certain icinga pages. CAS dose support ip authentication however we main be able to do something more robust

Event Timeline

jbond triaged this task as Medium priority.Nov 27 2019, 11:43 AM

Change 598742 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] cas-icinga: Add an entry point for the eternal monitoring script

https://gerrit.wikimedia.org/r/598742

I had a look at this on the CAS side and i think it would be doable to add some level of 2FA with an account in ldap. however i think most scripted users would only need to login to one service and not all services as such im not sure it makes sense to give scripted accounts a full SSO account as we would end up complicating things by applying additional ACL's for. Again we can restrict which services a specific account has access to on the CAS side however it seems to me that we are just adding complexity , both on CAS but also on the monitoring scripts which would need some type of session management.

Looking at the meta-monitoring script specifically i have created a patch which uses the basic auth file currently in use on icinga, if the connection comes from the wikitech-static ip address, otherwise CAS authentication is used. Let me know what you think

I had a look at this on the CAS side and i think it would be doable to add some level of 2FA with an account in ldap. however i think most scripted users would only need to login to one service and not all services as such im not sure it makes sense to give scripted accounts a full SSO account as we would end up complicating things by applying additional ACL's for. Again we can restrict which services a specific account has access to on the CAS side however it seems to me that we are just adding complexity , both on CAS but also on the monitoring scripts which would need some type of session management.

Full ack on avoiding complexity here.

Looking at the meta-monitoring script specifically i have created a patch which uses the basic auth file currently in use on icinga, if the connection comes from the wikitech-static ip address, otherwise CAS authentication is used. Let me know what you think

Following up in Gerrit.

Change 606437 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] profile::icinga: add vhost for external monitoring

https://gerrit.wikimedia.org/r/606437

Change 598742 abandoned by Jbond:
cas-icinga: Add an entry point for the external monitoring script

Reason:
https://gerrit.wikimedia.org/r/#/c/operations/puppet/ /606437

https://gerrit.wikimedia.org/r/598742

Change 606437 merged by Jbond:
[operations/puppet@production] profile::icinga: add vhost for external monitoring

https://gerrit.wikimedia.org/r/606437

Change 606675 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] profile::icinga::external_monitoring: add icinga[12]001-extmon aliases

https://gerrit.wikimedia.org/r/606675

Change 606678 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] acme_chief: add extmon names to SNI list of main icinga cert

https://gerrit.wikimedia.org/r/606678

Change 606675 abandoned by Jbond:
profile::icinga::external_monitoring: add icinga[12]001-extmon aliases

Reason:
not required

https://gerrit.wikimedia.org/r/606675

Change 606678 merged by Jbond:
[operations/puppet@production] acme_chief: add extmon name to SNI list of main icinga cert

https://gerrit.wikimedia.org/r/606678

jbond claimed this task.

Resolving this ultimatly we have decided that we will bypass SSO for automated accounts and use a method specific to the site in questions. this could be

  • an api key for the site
  • a differen vhost with different ACL's (bypassing sso)
  • something elses