D.2. Access control

D.2. Access control
	Appendix D. Scripted access

You will need to consider access control carefully if using scripts to access the FireBrick. In particular you need to ensure that someone that has access to the scripts, or simply a copy of the script, could gain unfettered access to your FireBrick(s).

D.2.1. Username and password

You will probably want to create a separate user for the script access, with a separate password. You can then make use of this with a command like curl using the --user= argument in the script.

Note

We do not recommend simply hard coding the password, and it may be better to have passwords stoted in a database of some sort. This will depend on your own security procedures.

D.2.2. OTP

You could, if you have the tools to manage OTP codes, make use of an OTP seed for your script user. Remember that the authentication system allows the OTP code to be pre-pended to the password, e.g. --user=name:123456password. This is recommended if using http access which can be snooped upon.

D.2.3. Allow list

We strongly recommend you have additional allow list access controls on your script user to lock down to machines which will be accessing the FireBrick. You may even want different users for different scripts, machines running scripts, and FireBricks depending on your own security policies.

D.2.4. Allowed access

It is likely that scripts, as described in this appendix, will not need to access or change the configuration on your FireBricks, and so you can lock down access for the user to restrict access to the config.

Note

If you do have scripts that update configuration, you may want this to user a different user for security reasons.


Appendix D. Scripted access		D.3. XML data for common functions