instruction: Create a Dockerfile for security
output: ```dockerfile
  From a security standpoint, it is best to
  avoid these situations.PrerequisitesThe subordinate UID and GID ranges must be associated with an existing user,
  even though the association is an implementation detail. The user owns
  the namespaced storage directories under /var/lib/docker/. If you don't
  want to use an existing user, Docker can create one for you and use that. If
  you want to use an existing username or user ID, it must already exist.
  Typically, this means that the relevant entries need to be in
  /etc/passwd and /etc/group, but if you are using a different
  authentication back-end, this requirement may translate differently.To verify this, use the id command:
  
  $ id testuser
  
  uid=1001(testuser) gid=1001(testuser) groups=1001(testuser)
  The way the namespace remapping is handled on the host is using two files,
  /etc/subuid and /etc/subgid. These files are typically managed
  automatically when you add or remove users or groups, but on some
  distributions, you may need to manage these files manually.Each file contains three fields: the username or ID of the user, followed by
  a beginning UID or GID (which is treated as UID or GID 0 within the namespace)
  and a maximum number of UIDs or GIDs available to the user. For instance,
  given the following entry:
  
  testuser:231072:65536This means that user-namespaced processes started by testuser are
  owned by host UID 231072 (which looks like UID 0 inside the
  namespace) through 296607 (231072 + 65536 - 1). These ranges should not overlap,
  to ensure that namespaced processes cannot access each other's namespaces.After adding your user, check /etc/subuid and /etc/subgid to see if your
  user has an entry in each. If not, you need to add it, being careful to
  avoid overlap.If you want to use the dockremap user automatically created by Docker,
  check for the dockremap entry in these files after
  configuring and restarting Docker.If there are any locations on the Docker host where the unprivileged
  user needs to write, adjust the permissions of those locations
  accordingly. This is also true if you want to use the dockremap user
  automatically created by Docker, but you can't modify the
  permissions until after configuring and restarting Docker.Enabling userns-remap effectively masks existing image and container
  layers, as well as other Docker objects within /var/lib/docker/. This is
  because Docker needs to adjust the ownership of these resources and actually
  stores them in a subdirectory within /var/lib/docker/. It is best to enable
  this feature on a new Docker installation rather than an existing one.Along the same lines, if you disable userns-remap you can't access any
  of the resources created while it was enabled.Check the limitations on user
  namespaces to be sure your use case is possible.Enable userns-remap on the daemonYou can start dockerd with the --userns-remap flag or follow this
  procedure to configure the daemon using the daemon.json configuration file.
  The daemon.json method is recommended. If you use the flag, use the following
  command as a model:
  
  $ dockerd --userns-remap="testuser:testuser"
  Edit /etc/docker/daemon.json. Assuming the file was previously empty, the
  following entry enables userns-remap using user and group called
  testuser. You can address the user and group by ID or name. You only need to
  specify the group name or ID if it is different
  ```