[bitnami/java:11]: curl has been removed from the latest version

[fabienOuedraogo]

Name and Version

bitnami/java:11

What steps will reproduce the bug?

1. Create a dockerfile based on bitnami/java:11
2. Run a curl request in dockerfile
3. Try to build the image

What is the expected behavior?

The build should pass successfully.

What do you see instead?

The build will be failed with not found curl command error

Additional information

No response

[zacharylund]

bitnami/php-fpm is impacted as well:

• bitnami/php-fpm:7.4 has wget but not curl.
• bitnami/php-fpm:8.0 is missing wget and curl.
• bitnami/php-fpm:8.1 is missing wget and curl.

[edeandrea]

I too am experiencing this. I'm using the postgresl images (bitnami/postgresql:14) and have had to back down to bitnami/postgresql:14.4.0.

[carrodher]

Hi, we have been working on removing non-needed dependencies to have more secure containers, reducing the attack surface and the container size. curl is not needed in those container images you’re mentioning, that’s why it was removed from the container.

You can use the install_packages script to install it if it is needed for your use case when creating your custom image based on Bitnami’s or using curl as part of any custom script.
Please take into account, Bitnami containers are non-root by default, in order to be able to install packages you will need to run the container as root (at least when installing the package)

[edeandrea]

You can use the install_packages script to install it if it is needed for your use case.

This would then imply I would need to build and maintain my own "custom" container image, whereas currently I'm just running bitnami/postgresql:14 and then there are a couple of scripts inside /docker-entrypoint-preinitdb.d that use curl.

I'm not currently building/pushing my own custom image for that, nor do I really want to.

[carrodher]

In that case, curl is not used by the PostgreSQL application but by a custom script you're loading assuming that curl is installed in the container. We reviewed when curl (and other packages) are used by the main application and remove it when it was not used.

If you are using curl in a custom ConfigMap mounted at /docker-entrypoint-preinitdb.d, you will need to install this package before running it, something like

apiVersion: v1
kind: ConfigMap
metadata:
  name: heroes-db-init
  labels:
    app: heroes-db
    application: heroes-service
    system: quarkus-super-heroes
data:
  get-data.sh: |-
    #!/bin/bash
    install_packages curl
    curl https://raw.githubusercontent.com/quarkusio/quarkus-super-heroes/main/rest-heroes/deploy/db-init/initialize-tables.sql --output /docker-entrypoint-initdb.d/1-init-tables.sql

In the same way, as those containers are non-root by default, maybe you will need to change the SecurityContext as well so the container is executed as root.

[edeandrea]

In my situation I can't make any assumptions about what flavor of Kubernetes the pod is running in nor what kind of permissions the current user/service account has, so if that requires elevated permissions to run install_packages then unfortunately its not going to be a viable solution for my use case.

[edeandrea]

Maybe I could use an init container with a shared volume. The init container could do what I need to do with curl. I'll investigate that.

[wibed]

@edeandrea is there a psql related use case?
i could imagine that if used as a pub/sub one would might want to "extend" the container functionalities.

[edeandrea]

I am not directly using psql. I'm just using curl to go fetch some data and pull it down into the container to get loaded into the database by the container.

The curl drops the file into /docker-entrypoint-initdb.d directory, which the bitnami postgresql image then picks up.

This capability (the ability to put a script into /docker-entrypoint-preinitdb.d) is the reason why I chose to use the bitnami images in the first place. It was easy and I didn't have to invent another solution (like use an init container).

I understand where you are coming from though - eliminate things you don't need and reduce your attack surface. I get it.

I will look at alternative solutions, but those solutions may take me away from using the bitnami images.

Building my own custom images that extend this one and maintaining them is not an option in my case.

[wibed]

@carrodher is it possible to instantiate sidecars containers?

i am not familiar but on a glance it appears to be a sidecars job. i couldn't recognize it if there was such a possibility in place.

[edeandrea]

It wouldn't be a sidecar I needed. It would be an init container. A sidecar stays running for the duration of the pod's lifecycle, whereas an init container runs before the main container.

In my case I could use an init container to run the curl and drop the result on the filesystem, which is shared with the main postgresql container.

[edeandrea]

This seems to do what I need it to do

---
apiVersion: v1
kind: Secret
metadata:
  labels:
    app: heroes-db
    application: heroes-service
    system: quarkus-super-heroes
  name: heroes-db-config
data:
  POSTGRES_DB: aGVyb2VzX2RhdGFiYXNl
  POSTGRES_USER: c3VwZXJtYW4=
  POSTGRES_PASSWORD: c3VwZXJtYW4=
type: Opaque
---
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: heroes-db
    application: heroes-service
    system: quarkus-super-heroes
  name: heroes-db-init
data:
  get-data.sh: |-
    #!/bin/bash

    curl https://raw.githubusercontent.com/quarkusio/quarkus-super-heroes/main/rest-heroes/deploy/db-init/initialize-tables.sql --output /docker-entrypoint-initdb.d/1-init-tables.sql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: heroes-db
    application: heroes-service
    system: quarkus-super-heroes
    app.kubernetes.io/part-of: heroes-service
    app.openshift.io/runtime: postgresql
  name: heroes-db
spec:
  replicas: 1
  selector:
    matchLabels:
      name: heroes-db
  template:
    metadata:
      labels:
        name: heroes-db
        application: heroes-service
        system: quarkus-super-heroes
    spec:
      initContainers:
        - name: get-data
          image: registry.access.redhat.com/ubi8-minimal:8.6
          workingDir: /docker-entrypoint-preinitdb.d
          command:
            - 'sh'
            - 'get-data.sh'
          volumeMounts:
            - mountPath: /docker-entrypoint-preinitdb.d
              name: heroes-db-init
            - mountPath: /docker-entrypoint-initdb.d
              name: heroes-db-init-data
      containers:
        - envFrom:
            - secretRef:
                name: heroes-db-config
          image: bitnami/postgresql:14
          name: heroes-db
          ports:
            - containerPort: 5432
          resources:
            limits:
              memory: 128Mi
            requests:
              memory: 32Mi
          volumeMounts:
            - mountPath: /bitnami/postgresql
              name: heroes-db-data
            - mountPath: /docker-entrypoint-initdb.d
              name: heroes-db-init-data
      volumes:
        - emptyDir: {}
          name: heroes-db-data
        - emptyDir: {}
          name: heroes-db-init-data
        - configMap:
            name: heroes-db-init
          name: heroes-db-init

[tonsV2]

I'm all in favor of reducing the attack surface but I think curl is used in a lot of init scripts. Including some of mine which is why I'm writing this. I feel that downloading sql or pgc files is a very common use case which ought to be supported out of the box.

[mulder999]

In that case, curl is not used by the PostgreSQL application but by a custom script you're loading assuming that curl is installed in the container. We reviewed when curl (and other packages) are used by the main application and remove it when it was not used.

If you are using curl in a custom ConfigMap mounted at /docker-entrypoint-preinitdb.d, you will need to install this package before running it, something like

data:
  get-data.sh: |-
    #!/bin/bash
    install_packages curl
    curl https://raw.githubusercontent.com/quarkusio/quarkus-super-heroes/main/rest-heroes/deploy/db-init/initialize-tables.sql --output /docker-entrypoint-initdb.d/1-init-tables.sql

In the same way, as those containers are non-root by default, maybe you will need to change the SecurityContext as well so the container is executed as root.

Find great to do cleanup in the container although it was done in a way that did not decrease size of the container image.
BTW also affected for my healthcheck in bitnami/wordpress. Will have to mount curl binary through a volume as install_packages cannot be used by non-root user.

Would have been nicer to define a new line of tags for such breaking change !

[javsalgar]

Hi,

My advice on this would be to use the bitnami/bitnami-shell image as an init container which downloads the .sql files, putting them in a volume.

[edeandrea]

Thanks. I solved it on friday in quarkusio/quarkus-super-heroes#157

[javsalgar]

Thanks for letting us know!

[carrodher]

Please note curl was added back to some development containers such as Java (#9884) and PHP (#9972); just to list some of the containers mentioned in this issue.

[tonsV2]

Hi,

My advice on this would be to use the bitnami/bitnami-shell image as an init container which downloads the .sql files, putting them in a volume.

Do you have a suggestion regarding how to use pgc files with such an approach?