How to organize security and compliance when migrating from IBM Cloud Foundry to IBM Cloud Code Engine.

Over the past year, I have moved most of my deployed solutions from IBM Cloud Foundry to IBM Cloud Code Engine. I shared my experience in a series of blog posts. In the first article, I talked about how to bind cloud services to the apps or microservices and what to consider in terms of code changes (if any). Then, I discussed various DevOps aspects and how to build, deploy and scale your app on Code Engine (and how it differs from Cloud Foundry). 

Today, I am going to compare Cloud Foundry and Code Engine security and how to organize your project. I’ll also take a look at compliance topics and point out how Code Engine integrates with related standard components of IBM Cloud. The bottom line is that Code Engine is based on common container technology like IBM Cloud Kubernetes Service and integrates with standard security and compliance services of IBM Cloud. Thus, for me, there were no surprises when migrating solutions from Cloud Foundry to Code Engine.

Organize it: Moving from space to project

With Cloud Foundry, you have learned to organize resources in organizations and spaces and to assign roles to users (i.e., RBAC — role-based access control). With Code Engine, you can continue in a similar way:

• Organizations in Cloud Foundry should be mapped to resource groups (RGs). They allow you to bundle (group) computing resources like Code Engine and service into a logical unit and assign IBM Cloud Identity and Access Management (IAM) privileges. Cloud Foundry org roles become IAM platform roles.
• Similar to a development space in a Cloud Foundry org, a Code Engine project within resource group is the way to manage everything for an app or solution. Cloud Foundry space roles map to IAM service roles (a Code Engine project equals a service).

The (regular) integration of Code Engine with IBM Cloud IAM provides the benefits of IBM Cloud identity and access management for all. Foremost, I would like to point out that you can (and should) use service IDs to decouple DevOps pipelines with Code Engine app deployments from personal accounts and user IDs. Access groups allow you to easily define a set of privileges once, then assign them by adding users, service IDs and trusted profiles to the access group.

The screenshot below shows the defined access policies within such an access group. That access group grants the necessary privileges to push a newly built container image to the private container registry and then update the deployed Code Engine app. The privileges are scoped to a Code Engine project, a specific resource group and region:

Often, when following the 12-factor app and cloud-native approach, a solution consists of multiple microservices. Each microservice could be managed and deployed as app within the same Code Engine project. It allows you to share credentials for code repository, container registry access, and more. To tighten security, you should make use of the visibility settings for Code Engine apps. They allow you to do the following:

• Make the app publicly accessible (e.g., the web app). 
• Keep the app private to the IBM Cloud network (e.g., an app/microservice to be accessed from other compute options or cloud services).
• Restrict access to the project itself. I recommend this for solution-internal microservices.

Using the org/space to resource group/project mapping and the related IAM roles and then adding network security on top, it is easy to keep or even enhance the security when moving from Cloud Foundry to Code Engine.

Control it: Utilize logging, monitoring and governance services

To control and govern my deployed apps on Code Engine, I used the IBM Cloud standard services. The Code Engine documentation provides details on each integration and how to get started:

• Code Engine sends records about user-initiated security-related activities to IBM Cloud Activity Tracker. The events relate to the lifecycle of various Code Engine objects, such as projects, apps, secrets or configmaps.
• Regular diagnostic console output of Code Engine apps is recorded by IBM Cloud Log Analysis. I have used the logs to debug my deployed apps and, using the timestamps attached to each log record, to look into runtime performance. The screenshot below shows IBM Log Analysis with diagnostic output of an app.
• However, typically, IBM Cloud Monitoring is the service for such kind of task. Code Engine integrates with it and there are many metrics available. They allow you to capture the current state of your apps or microservices.
• Code Engine is supported by the IBM Cloud Security and Compliance Center and its resource governance functionality.
• Finally, before deploying container images to Code Engine, you can make use of compliance-related tasks in CI/CD pipelines (continuous integration/continuous delivery). For inspiration, see the continuous compliance pipeline as part of the DevSecOps practice.

Depending on the type of solution or app, you may want to utilize all or just few of them. To me, what made it simple was that they are standard services on IBM Cloud, and I use them independent of Code Engine:

Conclusions

In my series of blog posts on migrating solutions from IBM Cloud Foundry to IBM Cloud Code Engine, I touched on service bindings and possibly required code changes and on building, deploying and scaling apps. Today, I discussed security and compliance topics, and how to organize privileges for your development project and make use of existing services to look into security, quality and performance issues.

I provided many links in this blog post. If you only want to bookmark few, I recommend these:

• My previous blog posts: “From Cloud Foundry to Code Engine: Service Bindings and Code” and “IBM Cloud Code Engine: Build, Deployment and Scaling Aspects“
• IBM Cloud Code Engine documentation on migrating from Cloud Foundry and the document Code Engine and security for an overview on how to enhance security of your  Code Engine projects.
• IBM Cloud documentation on best practices for organizing resources and assigning access.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.