Posted on March 29, 2019 10:57 pm
 |  Asked by Nicholas Sheridan
Print Friendly, PDF & Email

Hi forum,

I was wondering about how I can reduce ‘automation fear’ and I was pondering the worse case scenario – remote lockout; or more specifically, how I might be able to demonstrate due dilligence in mitigation of this problem.

“Protecting” sections of config seems like a good idea, my immediate thought was specifying key words in an authorisation policy, but this might be difficult to achieve.

Are there any features or ‘silver bullets’ on this, or is this really just a design consideration? Every management network seems at some point to route over some form of aggregation, so it might not be sufficient to state “`exclude “interface ma1″“` from config policy on an autoamtion account?


Posted by Himanshu Singh
Answered on April 9, 2019 5:36 am

Hi Nicholas,

You can use role based command authorization through TACACS or RADIUS, where you can set the permit/deny rules on the server itself.

The following config enables command authorization through TACACS or RADIUS server:
switch(config)#aaa authorization commands all default group ?
WORD Server-group name
radius Use list of all defined RADIUS hosts
tacacs+ Use list of all defined TACACS+ hosts

Or you can do local role based command authorization. A small example,
role network-automation
10 deny command bas[a-z]* < -- blocking bash shell access 20 deny command ma[a-z]* ss[a-z]* <-- blocking management ssh access 30 deny mode config command ^interface (Management|create).* <-- blocking access to management interface 40 permit command [a-z]* ! username ansible privilege 15 role network-automation secret sha512
aaa authorization commands all default local


Post your Answer

You must be logged in to post an answer.