Implementing zero trust principles in IBM Cloud Pak for Integration involves several key aspects: 1. Treating all identities (users, applications, components, administrators) as untrusted and establishing an identity perimeter. 2. Minimizing privileges by restricting what actions containers and service accounts can perform and limiting their access to secrets, the Kubernetes API, and the underlying operating system. 3. Implementing defense in depth across the network, with microsegmentation between environments, applications, and tiers to control inter-pod and inter-tier communication.

1. Implementing “Zero Trust” in
IBM Cloud Pak for Integration
Kim Clark
Integration Architect
IBM
James Hewitt
Cloud Pak for Integration Development Architect
IBM
© 2021 IBM Corporation
Recording: http://ibm.biz/cp4i-security-webinar
Slides: http://ibm.biz/cp4i-security-pdf

2. agile integration
APIM
APIM APIM
API Management
APIM
API Management
APIM
APIM
Integration
http://ibm.biz/agile-integration
…is largely about embracing cloud native principles in integration
http://ibm.biz/agile-integration-webinar
© 2021 IBM Corporation

3. Microservice architecture
Ingredients of cloud native from
Initial concepts Adoption hurdles Success factors
Agile
methods
Lifecycle
automation
DevOps and
site reliability eng.
Team
autonomy
Fine-grained
components
Appropriate
decoupling
Minimal
state
Immutable
deployment Zero
trust
Elastic, agnostic,
secure platform
Lightweight
runtimes
Operational
automation
Observability
and monitoring
Container technology
Agility through
Automation
Sustainably empowered
Secured by default
Managed in aggregate
People
Architecture
Technology
© 2021 IBM Corporation
http://ibm.biz/cloudnativedefined

4. What do we mean
by Zero Trust* in
the context of this
presentation?
Approaches/strategies
Threat modelling
Think like a hacker
Defense in depth
Buzz phrases
• Identity as a perimeter
• Micro segmentation
• Adaptive security
• …
Themes
• Assume any vulnerability will be exploited
• Don't trust anyone or anything
• Assume attackers are on the inside already
“Zero trust (ZT) is the term for an
evolving set of cybersecurity paradigms
that move defenses from static, network-
based perimeters to focus on users,
assets, and resources….”
NIST – Zero Trust Architecture (2020)
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
© 2021 IBM Corporation
* The term “zero trust” in computing has actually been around since at least
1994, but the concept and details have evolved significantly over time.

5. © 2021 IBM Corporation
Workload host
Operating System
Workload host
Operating System
Code
Workload host
Operating System
Code
admins
devs
users
SCM
An example
of the move
to defense
in depth
CICD pipeline
SCM
Container Platform
DevOps
& SRE Telemetry
Control
Plane
Workload host
Operating System
Container
Container
Code
Workload host
Operating System
Container
Code
Container
Code
Container
Code
Workload host
Operating System
Container
Code
Container
Code
Container
Code
Container
Code
users
Container
Code
Container
Code
Container
Code
Code
Code
Code
Code

6. IBM Cloud Pak for Integration
IBM Z
IBM LinuxOne
IBM Power Systems
End
points
IBM
Cloud
AWS Private
Google
Cloud VMware
Microsoft
Azure
Cloud Pak for Integration
Enterprise
messaging
End-to-end
security
Application
integration
Event
streaming
High speed
data transfer
API
management

7. Two perspectives on how zero trust affects Cloud Pak for Integration
1. How customers use the product
Cloud Pak for Integration
Enterprise
messaging
End-to-end
security
Application
integration
Event
streaming
High speed
data transfer
API
management 2. How we (IBM) architect the product
This presentation is
focused on how we
implemented the product.
The better we architect for
zero trust, the simpler it
will be for customers to use
it securely by default

8. Characteristics of modern
integration solutions?
Fine grained: Independently deployed
integrations, smaller queue managers.
Agnostic infrastructure: Container
platforms enabling operational
consistency and portability
Multi-style: Involving application
integration, API management,
messaging, events.
Hybrid-cloud: Integration is less
centralized, and often located nearer to
applications wherever they reside – in
any cloud or on premises.
© 2021 IBM Corporation
On premises
SaaS
SaaS
SaaS
SaaS
IaaS
PaaS
PaaS PaaS
Polyglot (e.g. microservice application)
• Language runtimes
• Specialist runtimes (e.g. integration)
Exposure points
• APIs
• Events

9. Some* perspectives
on Zero Trust
(*this is far from an exhaustive list)
1. Identity as a perimeter
2. Privileges should be minimized
3. Data must always be safe
4. Secrets…are secret
© 2021 IBM Corporation

10. Aspect 1:
Identity as a
perimeter*
End user identity
Application identity
Component identity
Administrator identity
(*this concept dates back to at
least 2004, probably further, but
it has significantly evolved)
Container
Platform
i
q
API Gateway
User +
Component
identity
Admin.
identity
SaaS
Application
User identity
(federated?)
Mobile
App.
Component
identity
User + App.
identity
Operator
User +
Component
identity
Component
identity
End
User
Component App.
Admin.
User
Component
identity
Identity types
Platform
Control Plane
i
Component
identity
© 2021 IBM Corporation
Integration
container
Messaging
container
i Integration
code
q Queue manager
definition

11. © 2021 IBM Corporation
Aspect 2:
Privilege
should be
minimized
Platform privileges
Host privileges
Resource privileges
Network privileges
Container
Platform
Integration
container
q
Messaging
container
i Integration
code
q Queue manager
definition
q
i
API Gateway
i i i
Operating
System
CPU
memory
disk
Operating
System
Operating
System
Operating
System
Operating
System
Platform
Control Plane
Operating
System
Hosts
Resources
Network

12. Aspect 3:
Data must
always be
safe
Data at rest
Data in transit
Data access Container
Platform
i
i
q
i
q
i
API Gateway
MQ channel (secured)
HTTPS
mTLS
Encrypted
on disk
Encrypted
on disk
© 2021 IBM Corporation
Integration
container
Messaging
container
i Integration
code
q Queue manager
definition

13. Aspect 4:
Secrets…
are secret
Separation from code
Opaque storage
Internal generation
Container
Platform
i
i
q
i
q
i
API Gateway
Certificates
for mTLS?
SaaS
Application
SaaS
Credentials
HSM
© 2021 IBM Corporation
Queue
Manager
Credentials
Service
bindings?
Vault?
etcd
SCM
Integration
container
Messaging
container
i Integration
code
q Queue manager
definition
Encrypted?
Encrypted?

14. Protecting against code attacks
1. Operating system
Access to the underlying operating system
impacts all containers on the worker node
Options: Security Context Constraint (SCC)
2. Network
Over network access to attack/infiltrate
other containers.
Options: Network policies, service mesh,
routes/services, namespaces
3. Kubernetes API
Manipulate the cluster causing the
controllers to take actions.
Options: Service accounts, role-based access control
(RBAC)
4. Secrets
Code could access credentials and
certificates
Options: Service accounts, RBAC, vault
Kubernetes
Master Nodes
Control Plane
API Server
Controllers
Kubernetes
Worker Node
CoreOS
Container
Code
Container
Code
Kubernetes
API access
Operating System
access
Network
access
© 2021 IBM Corporation
1
3
Kubernetes
Worker Node
Container
Code
2
Vault
4
Accessing
secrets

15. CICD pipeline
© 2021 IBM Corporation
How do you avoid bad code entering the system in the first place?
Container
Code
SCM
Container
Platform
DevOps
& SREs
Build Test Deploy
Control
Plane
Operator
Include
vulnerability
tests
Container
Code
Container
Code
Container
Code
Container
Code
Release
container
repository
Container
image
Code
Access only
via SCM,
no direct
deployment
Automated
pipeline
Certified
container
repository
Only pipeline
has access to
control plane
Immutable
deployment
image
Only operator
has permissions
to deploy, and
only to specific
namespaces
namespace
1
namespace
2
Deploy to
specific
namespaces
But zero trust principles mean you can’t
assume that even this is sufficient!

16. Kubernetes
Worker Node
How can code in a container attack via the Operating System?
An unrestricted containers have full access to the host hardware
and software. They could compromise the node and all
containers running on it.
Examples
• Install packet sniffers, bitcoin miners
• Run as root, make system calls with root access
• Mount any directory from the host filesystem (and therefore
read/write other pod’s data)
• Attack other components via the network
© 2021 IBM Corporation
CPU
memory disk
Container
Code
Container
Code
Operating
System
access
Network
Container
Code
Operating System

17. Security Context Constraints
OpenShift governs interaction of a container with the host via a Security
Context Constraints (SCCs). These control, what actions a pod can perform
(e.g. whether its containers can run as root), and what it has access to (host
files, network, ports etc.). SCCs are in fact assigned to the Pod which
implicitly limits what the containers within it can do.
SCC policy types are defined at cluster scope, the two most relevant of
which are:
• Restricted (default if none specified): Permits a container only safe
capabilities that cannot impact other containers on the node.
• Privileged (requires administrator action): Code can “break out” of its
container and impact other containers on the node.
And of interest:
• Anyuid (higher priority when available): Allows containers to run as
the ID embedded in the image.
When implementing “roll your own” containers it is often tempting to use
Privileged SCC because its easier.
IBMs development teams for the Cloud Pak for Integration are required
to use restricted SCC.
© 2021 IBM Corporation
Kubernetes
Worker Node
CPU
memory disk
Container
Code
Container
Code
SCC
controlled
access
CoreOS

18. Network attacks
External: (north-south) Attacker from
beyond the cluster, gains access to
the cluster network
Internal: (east-west) Compromised
code inside the cluster has access to
the internal cluster network
© 2021 IBM Corporation
Kubernetes
Worker Node
Container
Code
Container
Code
Kubernetes
Worker Node
Container
Code
External
attack
Internal
attack
Network

19. © 2021 IBM Corporation
Container platform micro-segmentation – by environment, application, tier
Container Platform
Workload
host
Workload
host
Workload
host
Workload
host
Workload
host
Workload
host
App A – Web tier
DEV
App A – Web tier
TEST
App B – Web tier
DEV
App B – Web tier
TEST
App A – Application tier
DEV
App B – Application tier
DEV
App A – Data tier
DEV
App B – Data tier
DEV
App A – Application tier
TEST
App B – Application tier
TEST
App A – Data tier
TEST
App B – Data tier
TEST
Workload
host
Workload
host
Workload
host
Workload
host
Workload
host
Workload
host
App A – Web tier
PROD
App B – Web tier
PROD
App A – Application tier
PROD
App B – Application tier
PROD
App A – Data tier
PROD
App B – Data tier
PROD

20. © 2021 IBM Corporation
Network defense in depth in Kubernetes
Container Platform
Workload host Workload host
Web tier
Application tier
Data tier
Protect pod boundary (a)
Restrict inter-pod communication (a, b)
Create multi-pod boundaries (a, c)
Control inter tier communication (a)
Control external access to the cluster (a, e)
Govern exposure by subscription (e)
Options
a) Network polices: These can specify
• Ingress and egress rules for traffic arriving and leaving the cluster
• Which pods, namespaces and IP blocks can communicate with one another.
b) mTLS: Pods themselves may additionally implement (mutual) TLS and credential
checking.
c) Mutli-tenant mode: OpenShift includes a mode in which namespaces are network
isolated, but then more granular network policies won’t work.
d) Service mesh: A service mesh such as Istio simplifies the securing of routing
between pods (e.g. mTLS). They also enable traffic management and enable many
other useful routing patterns.
e) API Management: Provides a governed API gateway, restricting access to APIs
based on application identity, also providing a portal for discovery and self
administration of API subscriptions.
Appropriate
isolation is enforced
at every level.
In IBM Cloud Pak for Integration, we provide network policies for all our pods. This
ensures they will work if customer introduces a deny all policy to a namespace (a
best practice). Note that if a service mesh is introduced, this implicitly introduces a
deny all policy.

21. How can code in a container attack via the Kubernetes API?
By default, Kubernetes injects a service
account token into every pod, making every
pod “authenticated”.
Examples
• Run other pods with different images, and
other service accounts.
• Read secrets
• Mount storage
• Denial of Service (break things)
• Change its own configuration
© 2021 IBM Corporation
Kubernetes
Master Nodes
Control Plane
API Server
Controllers
Kubernetes
Worker Node
CoreOS
Container
Code
Container
Code
Kubernetes
API access
3

22. Kubernetes API
Role based access control (RBAC)
The Kubernetes control plane looks after all the objects (resources) in
the cluster: Pods, Namespaces, ConfigMaps etc.
To query and manipulate those objects, you need to make requests to
the Kubernetes API. Command-line tools such as kubectl go through
this API, but you can also call it directly via REST.
You cannot interact with the API without an identity, and that identity
must be bound to a role that provides access to the objects you want
to work with.
Rules are set for roles defining precisely what action (verbs) can be
performed on what objects (resources).
Roles can be bound to namespaces (through role bindings), and
across all namespaces (through cluster role bindings).
Code in containers can also access the API, and it too needs an
identity. That identity is not a user. It is a service account.
IBM Cloud Pak for Integration minimizes the permissions in the
service accounts it uses. Any unusual permissions are qualified in
the documentation.
Kubernetes
Control Plane
Container
Code
Kubernetes
RBAC
Binding
Many
Many
Many
One
Role
Resources Verbs
Many
Many Many
© 2021 IBM Corporation
Rule
Kubernetes
API
Service Account
Service Account/User Account
User Account
One
One One

23. Kubernetes API
Service accounts & namespaces
Containers need an identity to interact with the
Kubernetes API server. That identity is not a user. It is a
service account.
Service accounts are namespace scoped.
• Each container pod is assigned exactly one of the
service accounts in a namespace.
• There is no restriction on which service accounts
in a namespace a pod can be assigned
• A namespace with a powerful service account is a
potential security risk
IBM Cloud Pak for Integration separates operators
and operands into different namespaces where
appropriate, providing each with only the permissions
it needs.
Kubernetes
Control Plane
© 2021 IBM Corporation
Container
Code
Operator
Container
Code
namespace2
Service Account D
has permission to
deploy code to
namespace2
namespace1
Kubernetes
API
Service Account D
Service Account A
Controller
Container
Code
Service Account B
Service Account C
Any service
account in the
namespace can
be assigned
Service Accounts A, B, and C
have minimal permissions
on Kubernetes API

24. How can code in a container attack via secrets?
Malicious code in a container has access to all
the secrets mounted by that pod. Additionally,
if the associated service account has privileges
it can read more secrets.
Within Kubernetes environments Vault access
is also often authenticated based on service
account.
Examples
• Get credentials for database access
• Get certificates to use in mTLS
© 2021 IBM Corporation
Kubernetes
Master Nodes
Control Plane
API Server
Controllers
Kubernetes
Worker Node
CoreOS
Container
Code
Container
Code
Accessing
Kubernetes
Secrets
Vault
Accessing
vaults

25. How should you manage access to secrets?
No secret information should ever be placed unencrypted in source control,
whether in code or configuration files, so what are the options?
K8s Secrets
• It is not encrypted by default, just placed in etcd, but it can be.
• By default they are namespace scoped. RBAC rules can perform
coarse grained access control.
• Administration of the secrets requires K8s access, so it is very
much a K8s only solution.
• K8s secrets are typically surfaced as files on a dedicated file mount
(although can be placed in environment variables).
• Where do you put the secrets before they get into K8s? What if you
need them in more than one namespace. What if the namespace
you stored them in gets removed, but you still need the secrets?
• No support dynamic generation of per-instance secrets
• No assistance with certificate rotation
© 2021 IBM Corporation
External secrets management such as HashiCorp Vault
• Encrypted by default and stored in a choice of persistence options.
• Fine grained access control. Can be linked to K8s service accounts.
• External to K8s so can be used for broader secrets requirements.
• Secrets can be retrieved at runtime, although a common model is
to have them injected onto the container file system.
• Provides a permanent secrets store with a lifecycle beyond
namespaces, clusters etc.
• Enables dynamic generation of per-instance secrets with, with
specific access controls (e.g. creation of credentials for “read-only”
access to a database, with automatic time and/or activity based
revocation).
• Can help with certificate rotation

26. There are always consequences to increased security.
Additional resources, more complex processes,
reduced agility etc.
No-one achieves “zero” in zero trust.
Threat modelling goes hand in hand with risk
assessment (‘What level of paranoia would you like to
adopt…’)
Mitigations at a given cost, provide you the best
compromise towards zero trust.
Thoughts on the
consequences of
zero trust
© 2021 IBM Corporation

27. © 2021 IBM Corporation
• Components and people should have no privileges by default
• All privileges are explicitly bestowed based on identity

28. More information
© 2021 IBM Corporation
Zero Trust
What is zero trust
https://www.ibm.com/topics/zero-trust
NIST – Zero Trust Architecture (2020)
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
Agile Integration and Cloud Native
Agile Integration
http://ibm.biz/agile-integration
What does cloud native really mean?
http://ibm.biz/cloudnativedefined
Cloud native agile integration
https://ibm.biz/agile-integration-cloud-native
IBM Integration
https://developer.ibm.com/integration
Cloud Pak for Integration
https://www.ibm.com/cloud/cloud-pak-for-integration
Staying up to date:
https://community.ibm.com/community/user/imwuc/globalgroups/cloudintegration
Detailed documentation
Cluster scoped permissions
https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.1?topic=reference-cluster-scoped-permissions
Security context constraints
https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.1?topic=reference-security-context-constraints
Certificate management
https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.1?topic=administration-replacing-default-keys-certificates
Role Management
https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.1?topic=administration-roles