I am looking for some guidance on how to handle permissions/access for an application build/deployment.
We need to allow for software deployments via Visual Studio Team Services and a build server running on Windows, deploying to RHEL 7 servers. We would like to use a service account, say 'srv_user', to handle the process. The need will be to:
Stop tomcat service on destination server
Push latest code to destination server
Do an 'ant' build of the code on destination server
Start tomcat service on destination server
Thoughts/Concerns:
It would be great if the srv_user didn't actually need shell access on the RHEL 7 servers so developers who know the credentials can't ssh into the server. However, given the need to do a build on the destination server that may be difficult. Any thoughts?
.
We want the tomcat service to run as a different user, say 'app_user'. Since the srv_user will need to stop and start tomcat to run the build, I'm thinking to use a custom systemd service that srv_user can run but starts the service as app_user. Does this sound like the best way to handle this need or is there a better way to handle it?
.
The srv_user will be in the same group as app_user but we do want the written files to be owned by app_user. What is the best way to handle file permissions? Is there a good way for srv_user to write files as app_user or is the only way to write and then do a chown/chmod?
Hopefully I haven't confused the need too much, any suggestions are appreciated.
Here are some general considerations/suggestions. To be more specific is too much dependant on the specific setting in your shop which is hard to appreciate from afar.
First, identify all the necessary roles and what they need to be allowed. You have already started that but you need that in more detail. Do not only define one role ("srv_user") but also the other roles necessary: i.e. "tester", "admin", ...
Only then sort through these specifications and see where they are different. i.e.:
Basic role "user": right1, right2, right3
Role "tester": like "user", but also right4, right5
Role "srv_user": like "tester" plus right6, right7, right8
etc..
This will give you a basic layout for a group hierarchy and which right should go to which group.
A few caveats: it is quite modern to use "ACLs" instead of classic UNIX privileges. This is a great way of getting yourself into deep kimchi beyond all means of maintenance. Experience shows that you end up (usually more sooner than later) with a heap of rights without any structure and no one knows or understands what is going on. Avoid that at all cost, even if it might appeal to you at first. In the long run it tends to be more a problem than a solution. A good (long-term!) solution is not one that does what you want but one that is also easy to understand and painless to maintain.
Have a look at "sudo", but do NOT overuse it! It is often possible to make up for planning deficiencies by overusage of a tool. In practically all cases this is a very bad idea in the long run. If an implementation looks cumbersome rather plan better than undergo the effort of the implementation.
If in LAN,i would go with NFS and a cron script on the clients.
You have one windows master build server which has multiple NFS mounts from clients (destination servers) you wish to push changes to.
NFS is supported on newer windows and gid / uid can be mapped via registry to tomcat unix/linux user on clients.
A cron job runs on clients which detects if a new file is copied and does the work (stop tomcat, deploy code or whatever, start tomcat).
Be careful you do not catch files while being copied, rename a file after copy to NFS share on the build machine to file you want that client (destination server) to process.
Using NFSv4 you could probably have one port open between build machine and clients.
It would not involve any kind of access expect copying a file via network share, but some shell code running in cron should be produced.
Have you considering deploying application(s) thru web tomcat interface instead ?
@bakunin and @Peasant thank you for your replies and suggestions. My apologies for not updating this thread sooner.
What I have ended up doing is:
Created an RSA key and put it in place on the destination server to allow for passwordless SSH connections from the build server. This gives me the ability to change the password for the 'srv_user' and not have a need to distribute the password.
Created a systemd service for Tomcat so that the processes are always run as 'app_user'. The 'srv_user' connects via ssh, uses sudo to stop Tomcat via the systemd service, does the get of new files, does a build, uses sudo to change permissions back to 'app_user' owner and group, and uses sudo to start Tomcat via systemd service.
So far it seems like the best way to handle the process. I'll be fine tuning it as we progress.