CCSK

 View Only
  • 1.  Immutable workloads

    Posted Dec 28, 2021 12:18:00 PM
    I have a question on the module - for immutable workloads - if version of image is replaced instead of patching - wouldnt it take away cache of current state of the application or process running on the image?

    This came while going through the training module as below: https://knowledge.cloudsecurityalliance.org/certificate-of-cloud-security-knowledge-foundation-exam-bundle/474889/scorm/1tr8waphbm11a

    ------------------------------
    Thanks,

    Gaurav
    ------------------------------


  • 2.  RE: Immutable workloads

    CSA Instructor
    Posted Dec 29, 2021 09:29:00 AM
    Interesting question @Gaurav Gupta. To me you destroy the container and implicitly replace. Also, you follow through blue green deployment to minimise any down time. I hope this helps and is in line with what you are looking for?​

    ------------------------------
    Abhinav Goyal
    ------------------------------



  • 3.  RE: Immutable workloads

    CSA Instructor
    Posted Dec 30, 2021 07:51:00 AM
    Edited by Moshe Ferber Dec 30, 2021 11:45:37 PM
    Hi Gaurav, 
    When you create applications that are built for immutable infrastructure, you need to address this challenges. There are design patterns that needs to be followed. Immutable applications don't store data on local disk, they keep their connections table and application state at 3rd party db for example. 
    Same design patterns are recommended not only for immutable, similar challenges happen with autoscaling. When the cloud provider start scale down instances you want to make sure no connection is lost, so you need to follow cloud applications design patterns. 
    This is one of the reasons lift and shift (transfer traditional applications to cloud) has bad reputation and is not recommended. 
    You can find additional resources about how to design cloud native applications at the cloud provide kb, here is an example:
    https://docs.microsoft.com/en-us/azure/architecture/best-practices/auto-scaling



    Hope this helps. 
    Moshe. 



    ------------------------------
    Moshe Ferber
    ------------------------------



  • 4.  RE: Immutable workloads

    Posted Dec 31, 2021 07:00:00 AM

    While I believe I had a differing definition of immutable workload Moshe is correct. You need to understand how your application is built and what the impact of auto scaling is. 

    Good point on lift and shift. Using needs to be carefully considered. I have seen it increase costs and result in a reduction in stability which may undermine efforts to migrate to the cloud, or otherwise derail well intended modernization efforts. 



    ------------------------------
    Lee Neely CISSP, CISA,CRISC, CISM, GMOB, GPEN, GPYC, GAWN, G
    CSA BOI
    Boise ID
    ------------------------------



  • 5.  RE: Immutable workloads

    Posted Dec 31, 2021 08:08:00 AM
    Dear all,
    Wish all of you and families Happy New Year.
    NIST SP 800-192 has published standard on Containerization Security. The main points related to auto-scaling ( scale in and out horizontally ) where VMs and containers can be added, destroyed or replaced. Auto-scaling also called as Elasticity.
    To achieve this , there are two critical properties - immutability and stateless
    Immutability is defined as unchanging over time or unable to be changed. The approach to change is to upgrade the image and deploy this image into a new VM or container. Then shut down the old VM and container.
    Stateless - wont retain date in the local storage. This allows for the VM or container to be shut-down. If your application requires data to be retained , then it has to be stored in a persistent database external to the VM or container.
    Brgds
    Ram


    ------------------------------
    Ram Marappan
    Trainer and consultant
    Self employed
    ------------------------------



  • 6.  RE: Immutable workloads

    Posted Dec 30, 2021 08:11:00 AM
    The container model is slightly different.
    The idea is that you don't patch the running container (you already know this) You patch the image, and provision a new container and workload is shifted to the new container, the old container is destroyed when the existing transactions complete to prevent loss of service. In traditional systems, we would quiesce the system prior to shutting down, patch and bring it back up. The container/cloud native model allows shifting of workload for updates/patches without the (visible) hard stop.

    I used the term cloud native because I'm considering a model where you are dynamically scaling your workload. 

    Immutable complicates things slightly. When it comes to persistent data you need to consider how that persistence is achieved to not lose access to data. Consider a database, or other data store, running in a cluster with replication, so every node has all the data, which means actions like I describe above are achievable. (You still must wait for transactions to complete before stopping a node, but new workload can be pointed to the other nodes) If you only have a single node, you're going to need some level of outage when updating it.





  • 7.  RE: Immutable workloads

    CSA Instructor
    Posted Dec 31, 2021 03:25:00 AM
    Adding to the other comments, and rephrasing them a bit. 

    The idea of immutable workloads is that they are 'stateless'. Otherwise, they wouldn't be immutable.
    The state is stored outside of the running container or VM (as the case may be).

    Typically this is a combination of a Redis cache and a database.

    And almost by definition, clearing a cache should not have adverse functional consequences, only performance consequences.

    ------------------------------
    Peter HJ van Eijk
    CCSK & CCAK trainer
    https://www.clubcloudcomputing.com/
    ------------------------------