From Cloud Foundry to Code Engine: Cloud Security and Compliance Considerations

4 min read

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:

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:

IAM access group to assign privileges for Code Engine and container operations.

IAM access group to assign privileges for Code Engine and container operations.

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:

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:

IBM Log Analysis showing console output of a Code Engine app.

IBM Log Analysis showing console output of a Code Engine app.

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:

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

Be the first to hear about news, product updates, and innovation from IBM Cloud