Configure GlassFish Server passwords in scripts or Docker

GlassFish Server uses passwords at multiple levels to secure your applications. In this article, you’ll find out about:

Common passwords used with GlassFish Server

For production deployments, security is very important. GlassFish server contains multiple security features to strengthen a production installation and protect it from potential attackers. Some of those features rely on using custom passwords and store the passwords in a secure way. We recommend using all of them in your production setup, if you care about security:

  • Master password – encrypts all sensitive information like other passwords, aliases, or certificate stores. Without the correct master password, it’s not possible to read the sensitive information from GlassFish configuration. it’s not even possible to start GlassFish server.
  • Admin password – secures access to the administration features of GlassFish server, for example access to the Admin UI, calling asadmin commands, or access to REST endpoints on the admin HTTP listener.
  • Aliased passwords – alias for custom passwords used in the configuration. Instead of using passwords in plain text, aliases encrypt passwords and allow using an alias (reference) in the configuration. When GlassFish reads the configuration, it translates the alias to the password, which is decrypted using the master password. Aliased passwords can’t be read in plain text, without knowing the GlassFish master password.
  • Other passwords – passwords needed by various GlassFish commands, e.g. to create an SSH node, or a user in a file security realm. They are automatically stored in GlassFish configuration in an encrypted form.

Specify passwords in GlassFish configuration

GlassFish offers 3 main ways to update configuration:

  1. Using web-based Admin UI
  2. Interactive ASAdmin CLI tool (to configure from a terminal)
  3. ASAdmin CLI tool in non-interctive mode (to configure from scripts)

The first 2 options are straightforward to use, if a password is required – you just type the password in a password field in the UI, or into the terminal when the CLI tool asks for the password.

However, for security reasons, it’s not possible to pass passwords as command line arguments if you need to specify a password in scripts. Most terminal shells retain the history of executed commands and passwords could remain in the history where a potential attacker could read them from. GlassFish allows a different way to specify passwords – using a password file.

Specify passwords in a password file

The key thing in working with passwords in scripts is to supply them in a file. Each ASAdmin command accepts argument --passwordfile  to instruct it to read all the necessary passwords from it to avoid asking for passwords interactively. It’s also possible to define a global password file using the environment variable AS_ADMIN_PASSWORDFILE and then reuse the same file for each command, without repeating the --passwordfile argument for each command. This is convenient and possible due to the fact that the password file can define different passwords for different commands.

In the password file, you can define the following passwords, among others:

  • master password with the name AS_ADMIN_MASTERPASSWORD , default value is “changeit
  • admin password with the name AS_ADMIN_PASSWORD, default is an empty password
  • alias password with the name AS_ADMIN_ALIASPASSWORD
  • user password with the name AS_ADMIN_USERPASSWORD

You can find the list of all possible password names in the documentation of the ASAdmin CLI tool in the official GlassFish documentation.

For example, if we need to run a command with admin password “mypassword”, the next line has to be in the password file:

AS_ADMIN_PASSWORD=mypassword

And then we can use the password with the --passwordfile argument, like this:

asadmin list-applications --passwordfile=mypasswordfile

The above command won’t wait for typing the password but will instantly list all applications on the server. If the password is incorrect, the command would fail.

Change master and admin passwords in scripts

In most cases, you will only need to specify a single password for an ASAdmin command. Or multiple passwords, but they will be of a different kind, and hence will have a different name in the password file. However, the commands change-master-password to change the master password and change-admin-password to change the master password, they would ask for 2 passwords – the old one and the new one. Therefore we need to specify 2 passwords in a file for the same kind of passwords.

The solution is to add another variable for a new password into the same password file. Variables for new passwords are prefixed with AS_ADMIN_NEW  prefix, e.g. AS_ADMIN_NEWMASTERPASSWORD (for master password) or AS_ADMIN_NEWPASSWORD (for admin password).

For example, to change the master password, we need the next 2 lines in our password file:

AS_ADMIN_MASTERPASSWORD=oldmasterpassword
AS_ADMIN_NEWMASTERPASSWORD=newmasterpassword

And then we can use the 2 passwords with the –passwordfile argument, like this:

asadmin change-master-password --passwordfile=mypasswordfile

The above command won’t wait for typing or retyping any password but will instantly change the master password on the server to newmasterpassword . If the old password is incorrect, the command would fail.

NOTE: When changing the master password, consider using the --savemasterpassword=true argument to the change-master-password command. This will save the new master password on the file system so that GlassFish knows the master password when you start it. Otherwise you will need to provide the master password each time you start GlassFish. Saving the master password is insecure, but sometimes convenient, especially when starting GlassFish from scripts.

Change master and admin passwords in Docker

If you use the official GlassFish Docker image, you can specify the master and admin passwords for each Docker container at startup, e.g. using an environment variable. Or you can change them in a derived image, which changes them for all your GlassFish Docker containers.

Change passwords in the GlassFish Docker container at startup

It’s possible to configure master and admin passwords when starting the official GlassFish docker container. This is convenient if you want to configure both the passwords using an environment variable when starting the container, instead of wiring the passwords into a Docker image.

Since the Docker image for GlassFish 7.0.21, it’s very easy. Just specify the AS_ADMIN_MASTERPASSWORD and AS_ADMIN_PASSWORD environment variables:

docker run -p 4848:4848  -p 8080:8080 -e AS_ADMIN_PASSWORD=newpassword -e AS_ADMIN_MASTERPASSWORD=newmasterpassword ghcr.io/eclipse-ee4j/glassfish

If these environment variables are specified, the docker container will first change the passwords and then start GlassFish server as usual. If the admin password is specified, it will need to start GlassFish server, apply the change, then stop the server, and then start the GlassFish server as usual. This means that GlassFish server will be started twice. This is not optimal. It’s better to create a custom docker image and change the admin password during build time.

With the Docker image for GlassFish 7.0.20 or older, it’s not so straightforward. There we need to do several steps:

  1. Specify the command line for Docker run command to start a bash script instead of the standard startserv script.
  2. In the bash script, create a password file that contains passwords retrieved from environment variables.
  3. In the bash script, execute the change-admin-password or change-master-password command.
  4. Execute the startserv command as the main process to launch GlassFish server as usual.

This will add some actions before the normal GlassFish startup, which happens in point 4.

An example Docker command that runs GlassFish with a custom admin password “newpassword” would look like this:

docker run -p 4848:4848 -p 8080:8080 -e AS_ADMIN_PASSWORD=newpassword ghcr.io/eclipse-ee4j/glassfish /bin/bash -c 'echo -e "AS_ADMIN_PASSWORD=admin\nAS_ADMIN_NEWPASSWORD=$AS_ADMIN_PASSWORD" > passwordfile && asadmin change-admin-password --passwordfile=passwordfile && exec startserv'

Change the admin password in a derived Docker image

The admin password can also be changed while GlassFish server is stopped. This is convenient in Docker, because we can change the admin password in a similar way as the master password, without starting GlassFish server. Here’s an example Dockerfile that changes both the master and admin passwords (the file passwordfile contains all the passwords):

FROM ghcr.io/eclipse-ee4j/glassfish

# create a password file with the old and new password for the master and admin password
RUN echo 'AS_ADMIN_PASSWORD=admin\nAS_ADMIN_NEWPASSWORD=newpassword\nAS_ADMIN_MASTERPASSWORD=changeit\nAS_ADMIN_NEWMASTERPASSWORD=newpassword' > passwordfile

# execute asadmin command to apply the new master password
RUN asadmin change-master-password --passwordfile=passwordfile --savemasterpassword=true

# execute asadmin command to apply the new admin password
RUN asadmin change-admin-password --passwordfile=passwordfile

# remove the passwords from the filesystem
RUN rm -rf passwordfile

Then build and run the Docker image (also bind the admin port 4848)

docker build -t my-glassfish .
docker run -ti -p 4848:4848 my-glassfish

Then you can try logging into the Admin UI with the new admin password: https://localhost:4848

Change the master password in a derived Docker image

You can also create a custom Docker image derived from the official GlassFish image and configure the server, including the passwords, in the image. This way, the configuration is prepared before a container is started. When a container is executed, the configuration is already in place and the container starts faster.

When you create a custom Docker image based on an official GlassFish image, you can specify passwords with a custom password file, and change them using the asadmin tool.

To change the master password, note the following

  • GlassFish server should not be running when the change-master-password command is executed
  • Add the --savemasterpassword argument to the change-master-password command. Otherwise GlassFish will not know the new password and will fail to start. Alternatively, specify the master password in a password file and use it as a global password file using the AS_ADMIN_PASSWORDFILE environment variable

Below is an example custom Dockerfile to change the default master password “changeit” to “newpassword”:

FROM ghcr.io/eclipse-ee4j/glassfish

# create a password file with the old and new master password
RUN echo 'AS_ADMIN_MASTERPASSWORD=changeit\nAS_ADMIN_NEWMASTERPASSWORD=newpassword' > passwordfile

# execute asadmin command to apply the new master password
RUN asadmin change-master-password --passwordfile=passwordfile --savemasterpassword=true

# remove the passwords from the filesystem
RUN rm -rf passwordfile

With the above Dockerfile in your current directory, you can build your custom docker image with:

docker build -t my-glassfish .

And then run my-glassfish Docker image instead of ghcr.io/eclipse-ee4j/glassfish:

docker run -ti my-glassfish

You can verify that the master password is changed in the docker container when you run it with:

docker run -ti --rm --entrypoint keytool my-glassfish -list -keystore glassfish/domains/domain1/config/keystore.jks

It will ask for the master password. If you type the new master password, you should see the contents of the key store with the list of certificates. If not, you either typed a wrong password or the master password wasn’t changed and the configuration still uses the default “changeit” password.

Conclusion

To sum it up, GlassFish offers flexible and secure options for managing passwords. You can automate password setup with asadmin and password files in non-interactive scripts, preconfigure them in custom Docker images, or pass them dynamically as environment variables or command-line arguments at container startup. These options make it easy to adapt to any deployment scenario while ensuring security and consistency.

Leave a Comment

Your email address will not be published. Required fields are marked *

Captcha loading...

Scroll to Top