Leveraging security to your service mesh
with Istio and Kiali
@xeviknal
@kialiProject


Xavier Canal
@xeviknal
@kialiProject

Agenda
-
New paradigm, new security concerns
-
Istio security features
-
Auto-discovery
-
Mutual TLS
-
RBAC
-
Audit
-
-
Q&A
@xeviknal
@kialiProject

Monolith to Microservices
@xeviknal
@kialiProject

NEW SECURITY CONCERNS
NEW PARADIGM
@xeviknal
@kialiProject

Target discovery
@xeviknal
@kialiProject

Lots of services to protect
Services are dynamic
Multiple workloads per service
Few components to protect
Pieces are very well-known
Almost static architecture
Impersonation
@xeviknal
@kialiProject

One point per service
Higher network usage
Few points to impersonate
Data protection
@xeviknal
@kialiProject

Each service receives and sends data
Higher network usage
Few components to protect
Access Control
@xeviknal
@kialiProject

Each service has at least one endpoint
Consumers need to be identified
Multiple workloads to protect
Few public points
Consumers are unknown
Audit
@xeviknal
@kialiProject

Each service may have unauthorized access
Few access points to log
ISTIO
PROTECTING
THE SERVICE MESH
@xeviknal
@kialiProject

WITH
SECURITY BY DEFAULT
No changes needed for application code and infrastructure
@xeviknal
@kialiProject

DEFENSE IN DEPTH
Integrate with existing security systems to provide multiple layers of defense
@xeviknal
@kialiProject

ZERO-TRUST NETWORK
Build security solutions on untrusted networks
@xeviknal
@kialiProject

HOW?

@xeviknal
@kialiProject

Auto-discovery
- Discover all the pieces you have to protect
- Almost real time discovery
- Detect unexpected connections between services
@xeviknal
@kialiProject

SERVICE MESH
Demo
Deployment
apiVersion: v1
kind: ServiceAccount
metadata:
name: bookinfo-productpage
---
apiVersion: v1
kind: Service
metadata:
name: productpage
labels:
app: productpage
spec:
ports:
- port: 9080
name: http
selector:
app: productpage
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: productpage-v1
spec:
replicas: 1
template:
metadata:
labels:
app: productpage
version: v1
spec:
serviceAccountName: bookinfo-productpage
containers:
- name: productpage
image: istio/examples-bookinfo-productpage-v1:1.8.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080- Only Kubernetes entities
- Needs Istio sidecar injection
istioctl kube-inject -f step1.yaml |kubectl apply -f
@xeviknal
@kialiProject

auto-discovery
Strong Identity
- Provide identity to each workload
- Necessary for:
- mTLS
- RBAC
- Secure naming
@xeviknal
@kialiProject

SPIFFE
- Secure Production Identity Framework For Everyone
- Creates a universal naming convention
- How to encode that name in a X.509 file (SVID)
- How a client validates a X.509 certificate to authenticate the SPIFFE identity
@xeviknal
@kialiProject

Strong Identity - how?
cat chain-example.pem | openssl x509 -noout -text


@xeviknal
@kialiProject

Mutual TLS Authentication
@xeviknal
@kialiProject

Are you who you say you are?
Mutual TLS Authentication
- Ensure both ends of communications are legit
- Encrypt service-to-service communications
- Envoy and Pilot involved (secure naming)
@xeviknal
@kialiProject

Demo
@xeviknal
@kialiProject

Secure naming
Is identity A allowed and authorized to run service B?
e.g. infra-team is allowed and authorized to run productpage.bookinfo
| Identity | Service |
|---|---|
| infra-team | productpage.bookinfo |
| infra-team | ratings.bookinfo |
| test-team | productpage.staging |
@xeviknal
@kialiProject

Enabling mTLS
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "details-enable-mtls"
spec:
host: details
trafficPolicy:
tls:
mode: ISTIO_MUTUALAuthentication methods accepted on workload(s)
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "default"
namespace: "bookinfo"
spec:
peers:
- mtls:
mode: PERMISSIVERules applied on client-side after routing
@xeviknal
@kialiProject

Policy
DestinationRule
kubectl apply -f step3.yaml -n bookinfo
@xeviknal
@kialiProject

service and namespace mTLS
kubectl apply -f step4.yaml -n bookinfo
@xeviknal
@kialiProject

mesh-wide mTLS
@xeviknal
@kialiProject

Can ServiceA perform Action on ServiceB?
RBAC system
RBAC system
- Fine-grained access policy
- Consistent and homogeneous across the mesh
- Talks about services and versions
instead of pods, deployments - Strong identities needed
@xeviknal
@kialiProject

Demo
ServiceRole
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: details-reviews-viewer
namespace: bookinfo
spec:
rules:
- services:
- "details.bookinfo.svc.cluster.local"
- "reviews.bookinfo.svc.cluster.local"
methods: ["GET"]
constraints:
- key: "destination.labels[version]"
values: ["v1"]
List of permissions:
- Object: Service
- Action: method + Path
@xeviknal
@kialiProject

ServiceRole
Binding
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: bind-details-reviews
namespace: bookinfo
spec:
subjects:
- user: "cluster.local/ns/bookinfo/sa/bookinfo-productpage"
roleRef:
kind: ServiceRole
name: "details-reviews-viewer"List of subjects attached to a role:
- Authenticated SVC
- Authenticated end-user
@xeviknal
@kialiProject

kubectl apply -f step5.yaml -n bookinfo
@xeviknal
@kialiProject

reviews and details v1 only
Auditing
- Distributed traces
- Logging
@xeviknal
@kialiProject

THE SERVICE MESH
Demo
@xeviknal
@kialiProject

Logs and traces
Leverage security with:
- Auto-discovery
- Mutual TLS
- RBAC system
- Distributed Tracing
- Logging
@xeviknal
@kialiProject

THANKS
@xeviknal
@kialiProject

Leveraging security to the Service Mesh with Istio and Kiali
By Xavier Canal Masjuan
Leveraging security to the Service Mesh with Istio and Kiali
Industry is moving into microservices architectures from monolith ones. Hence, security concerns are changing due to this paradigm change. Let's see what Istio and Kiali provide to address those security issues.
- 175