[Deployment] [Containers] Refining WSO2 Dockerfile structure

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Deployment] [Containers] Refining WSO2 Dockerfile structure

Dilan Udara Ariyaratne
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

lakmal Warusawithana
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

lakmal Warusawithana
Please note: To see the security vulnerabilities in these images, you need to sign in to docker hub.

On Wed, Dec 20, 2017 at 2:30 PM, Lakmal Warusawithana <[hidden email]> wrote:
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692





--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

lakmal Warusawithana
added few screenshots as reference






On Wed, Dec 20, 2017 at 4:49 PM, Lakmal Warusawithana <[hidden email]> wrote:
Please note: To see the security vulnerabilities in these images, you need to sign in to docker hub.

On Wed, Dec 20, 2017 at 2:30 PM, Lakmal Warusawithana <[hidden email]> wrote:
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692





--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692





--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

Imesh Gunaratne-2
In reply to this post by lakmal Warusawithana
On Wed, Dec 20, 2017 at 4:49 PM, Lakmal Warusawithana <[hidden email]> wrote:
Please note: To see the security vulnerabilities in these images, you need to sign in to docker hub.

​Thanks for pointing out Lakmal! We will go through this in detail and do the needful to overcome the security issues.

Thanks
Imesh

On Wed, Dec 20, 2017 at 2:30 PM, Lakmal Warusawithana <[hidden email]> wrote:
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692





--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692





--
Imesh Gunaratne
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: <a href="tel:+94%2077%20374%202057" value="+94773742057" target="_blank">+94 77 374 2057
W: https://medium.com/@imesh TW: @imesh 
lean. enterprise. middleware


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

Godwin Amila Shrimal
In reply to this post by lakmal Warusawithana
We are not recommending/supporting to run WSO2 products on OpenJDK according to our documentation [1].

[1] https://docs.wso2.com/display/CLUSTER44x/Production+Deployment+Guidelines


Thanks
Godwin

On Wed, Dec 20, 2017 at 2:30 PM, Lakmal Warusawithana <[hidden email]> wrote:
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Godwin Amila Shrimal
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94772264165

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

lakmal Warusawithana
True, IMO we should revisit with Java 8. Products level we should verify it first.

On Wed, Dec 20, 2017 at 7:50 PM Godwin Shrimal <[hidden email]> wrote:
We are not recommending/supporting to run WSO2 products on OpenJDK according to our documentation [1].

[1] https://docs.wso2.com/display/CLUSTER44x/Production+Deployment+Guidelines


Thanks
Godwin

On Wed, Dec 20, 2017 at 2:30 PM, Lakmal Warusawithana <[hidden email]> wrote:
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Godwin Amila Shrimal
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94772264165
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Sent from Gmail Mobile

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Deployment] [Containers] Refining WSO2 Dockerfile structure

Dilan Udara Ariyaratne
Thanks, Lakmal for the valuable insight.

Of-course, we will have to revisit our strategy on openJDK as it is now the official reference implementation for java.

And if we are to publish our images to any public repositories like dockerhub, images baked with openJDK may serve well for us.

Considering the base OS image options we do have, how about alphine [1] over Ubuntu [2] ?

Considerably small image size and lower vulnerability ratio (1/6), compared to Ubuntu (1/4) and IIRC, we have already had a discussion on making alphine, our base image way back in 2016.

Bringing a base OS and JDK level change in the short-run may not even be feasible, but it's good to have this discussion going for the long-run.






Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware


On Wed, Dec 20, 2017 at 9:26 PM, Lakmal Warusawithana <[hidden email]> wrote:
True, IMO we should revisit with Java 8. Products level we should verify it first.

On Wed, Dec 20, 2017 at 7:50 PM Godwin Shrimal <[hidden email]> wrote:
We are not recommending/supporting to run WSO2 products on OpenJDK according to our documentation [1].

[1] https://docs.wso2.com/display/CLUSTER44x/Production+Deployment+Guidelines


Thanks
Godwin

On Wed, Dec 20, 2017 at 2:30 PM, Lakmal Warusawithana <[hidden email]> wrote:
Hi Dilan,

Did we evaluate any other base images?  Official Ubuntu base images are having some vulnerabilities [1] . OpenJDK docker images [2] are more secure and lighter than the ubuntu base images. Can't we run our product in openJDK? Shall we have a look. If we can't find any suitable public base image, shall we create our owned one? 



On Wed, Dec 20, 2017 at 12:12 PM, Dilan Udara Ariyaratne <[hidden email]> wrote:
Hi Folks,

As part of our container based installation experience, the usage of dockerfiles play a vital role 
in generating the required container images specific for a deployment.

Pretty recently, we went through a few major refinements to our product docker repositories, manly addressing :
[1] Simplification of docker image build process and then, [2] Refining dockerfile structure, to meet industry standards.

Simplification basically involved replacing both dockerfile and shell command based hybrid image build process (Refer to Architecture Mail Thread: [Dockerfiles] Simplified Approach for wso2/dockerfiles), solely with native dockerfiles 
and the resulted structure of a refined dockerfile for a particular product profile (or runtime) is as follows.





​Steps in detail :

[1] Set UBUNTU latest LTS release as base image :
In here, we always set the latest Long-Term-Supported (LTS) Docker Image of UBUNTU as the base OS Image for our containers.
The primary reason for using an LTS release of Ubuntu is that we can depend on it being regularly updated and therefore, secure and stable.

[2] Install Utility Packages :
Sole purpose of installing a few utility packages in to the container image is to make the environment ready for rest of docker build instructions installing software (i.e. unzip)
and for troubleshooting purposes of the containers (i.e. telnet, iproute2 and curl).

[3] create a non-root user (non-privileged), user's home directory and group :
Why non-root user ? This is to strip the container from all the potentially dangerous system capabilities and prevent any damage a malicious access could do to the system. Since both containers and host machines do share 
the same kernel space, having an attacker accessing the container as root could bring in more issues as root user is the easiest to be taken advantage to attack the kernel with any existing flaws if any.

[4], [5] and [6] Install JDK and WSO2 Product into user's home directory and then, set minimum required permissions to the created non-root user and the group :
User's home directory will be the only file system area that the created non-privileged user and the users who are in the group would have full access with all read, write and execute permissions.
This will also be the location in to which both JDK and a WSO2 product will be installed with appropriate minimum required permissions to the user as well as the group.

[7] Set user from root to non-root user :
This will set the user to be used when running the image and for the subsequent ENTRYPOINT instruction that follow it in the Dockerfile. 
As a result, when running the container, WSO2 server process will get initiated by this non-root user.

[8] and [9] Expose ports and entrypoint to the starter script :
These two instructions are always specific to a product profile since the ports that we need to expose and the starter scripts with any command options that we need to run as entrypoints do differ from profile to profile.


Reference Implementations and Documentation :

We have already adopted this approach in defining dockerfiles for many of our WSO2 products, namely :

Please have a look and feel free to share your thoughts or any issues on any of these implementations, so that it will also help us in fine-tuning our existing platform-wide guidelines on this purpose. 

Thanks,
Dilan.

Dilan U. Ariyaratne
Senior Software Engineer
WSO2 Inc.
Mobile: +<a href="tel:%2B94766405580" value="+94766405580" target="_blank">94766405580
lean . enterprise . middleware

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Godwin Amila Shrimal
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94772264165
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Sent from Gmail Mobile

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture