lucee-dockerfiles
lucee-dockerfiles copied to clipboard
Remove lucee admin entirely from image
While it might be beneficial in development to have access to the admin, this security risk should be removed entirely from the base image. Developers can always reinstate the admin within their own project Dockerfile.
To turn the admin on in Lucee 5, you have 2 (soon 3) options.
- take the admin extension out of the local extension provider and copy it to the deploy folder
- define the admin in the start script and restart lucee
- (not working yet) enable the admin in your code by installing it (only possible for trusted sources).
So <cfset extensionInstall(“lucee-admin”,”1.0.0.0.0”)><!— second param is optional —>
For Lucee 4 remove the admin mapping in /WEB-INF/lib/lucee-server/context/lucee-server.xml
:
<mapping archive="" inspect-template="once" listener-mode="modern" listener-type="curr2root" physical="{lucee-server}/context/" primary="physical" readonly="yes" virtual="/lucee-server/"/>
<mapping archive="{lucee-config}/context/lucee-context.lar" inspect-template="once" listener-mode="modern" listener-type="curr2root" physical="{lucee-config}/context/" primary="physical" readonly="yes" virtual="/lucee/"/>
Comment out or remove:
<!--<mapping archive="{lucee-config}/context/lucee-context.lar" inspect-template="once" listener-mode="modern" listener-type="curr2root" physical="{lucee-config}/context/" primary="physical" readonly="yes" virtual="/lucee/"/>-->
Bum-steer on the Lucee 4 admin removal; causes Lucee to crash.
Can look to block admins on NGINX versions with a rewrite. Need another solution for the base image.
Default.conf for NGINX builds now blocks admin by default:
location ^~ /lucee {
deny all;
}
Can be easily changed by developers adding their own conf -- which is generally needed to run a site in any event.
:+1: I enjoy seeing this "secure by default."
agree for *nix, disagree for win docker. there is no need to remove if it rewrite is in place to limit to local use. (not that I like the admin, it's a dogs breakfast stuck in 2005 as far as functionality), but all the same. Any limitations should be on cfadmin tag/script as this should be where everything is secured back to.
I do like the idea the default admin should be an 'lucee extension'. This also then allows for custom admin panels to replace the main one limiting the attack surface as you only have to roll as much admin panel as you need for your own deployment = I very much like this idea. (but the rule should be in there also if it stays)
I am finding that even with
location ^~ /lucee { deny all; }
I am still able to access the lucee admin. Any ideas?
@cutterbl I can't replicate access to the admin if you have this in place:
location ^~ /lucee {
deny all;
}
Exactly what URL are you using to get something other than a 403 security response?
@modius Hello, you mentioned two way to turn on admin interface :
- take the admin extension out of the local extension provider and copy it to the deploy folder
- define the admin in the start script and restart lucee
Could you explain how to do that for the newbie who I am. 😄
It would be interesting to have a environment variable for docker which allow to turn on this interface. Or even better, allow us to choose the url, or autorize one IP adress. 😄
Unfortunately, we don't have the options we had hoped in Lucee 5. We can't readily undeploy/remove the Admin and have to suffice with blocking it on the URL for the time being. We're working with the Lucee committers to provide appropriate ENV options for turning the Admin "on and off".
@modius , I know this is an ancient report but did any headway get made for disabling the admin? An nginx rule is great for now but it's no substitute for disabling it entirely.
We don't yet have a solution for completely removing the admin while still allowing users to easily enable it for development purposes.
However, in Lucee 5.3.4.x+ there is a new change where you can no longer set an admin password by browsing to the admin URLs, which effectively means if there is no admin password set then the admin is not usable and the cfadmin tag is not usable.
https://luceeserver.atlassian.net/browse/LDEV-926
It's a step in the right direction, but I'd still prefer a native switch (e.g. an env var) to ensure requests to the admin just return a 404.
Would the lucee-light versions solve this issue?
There's also an environment variable you can set in your own child images to disable the admin, so we should close this WONT_FIX ?
having the admin in the default Docker image is super useful for solving problems (like the cfconfig JSON format not being documented) as well as learning what changing a setting does.
I think we can close.
If you need to disable the lucee admin, you can add
ENV LUCEE_ADMIN_ENABLED=false
to the child image.