istio service security

istio RBAC (Role Based Access Control)

istio RBAC supports namespace-level, service-level, and method-level service access control.
Role-Base semantics, support service-to-service, user-to-service
authentication
The authentication-related instance of the properties mixer of roles and role-bindings can be flexibly defined as authorization

apiVersion: "config.istio.io/v1alpha2"
kind: authorization
metadata:
  name: requestcontext
  namespace: istio-system
spec:
  subject:
    user: source.user | ""
    groups: ""
    properties:
      service: source.service | ""
      namespace: source.namespace | ""
  action:
    namespace: destination.namespace | ""
    service: destination.service | ""
    method: request.method | ""
    path: request.path | ""
    properties:
      version: request.headers["version"] | ""

subject: Define a series of properties to identify the caller.
action: defines which services can be accessed.
The authentication-related handler of the mixer is rbac

apiVersion: "config.istio.io/v1alpha2"
kind: rbac
metadata:
  name: handler
  namespace: istio-system
spec:
  config_store_url: "k8s://"
  cache_duration: "30s"

---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: rbaccheck
  namespace: istio-system
spec:
  match: destination.namespace == "default"
  actions:
  # handler and instance names default to the rule's namespace.
  - handler: handler.rbac
    instances:
    - requestcontext.authorization

config_store_url: Defines the source from which RBAC engine obtains RBAC policies, the default is "k8s://", which is obtained from the kubernetes API server.
cache_duration: Defines the duration for which authorization results are cached.
The rule created above will define the instance requestcontext.authorization of the cache authorization and the handler handler.rbac together.

istio RBAC Policy

istio RBAC Policy includes ServiceRole and ServiceRoleBinding.
ServiceRole: Defines the role to access the service.
ServiceRoleBinding: Give a user (a user, a user group, a service) a role.

apiVersion: "config.istio.io/v1alpha2"
kind: ServiceRole
metadata:
  name: products-viewer
  namespace: default
spec:
  rules:
  - services: ["products.default.svc.cluster.local"]
    methods: ["GET", "HEAD"]
---
apiVersion: "config.istio.io/v1alpha2"
kind: ServiceRoleBinding
metadata:
  name: test-binding-products
  namespace: default
spec:
  subjects:
  - user: "[email protected]"
  - properties:
      service: "reviews.abc.svc.cluster.local"
      namespace: "abc"
  roleRef:
    kind: ServiceRole
    name: "products-viewer"

Service, methods, and paths in ServiceRole belong to the dimension of requestcontext.authorization that defines action.
The user, group, and properties of the subjetcs value in ServiceRoleBinding belong to the dimension of the requestcontext.authorization definition subject.

istio service configuration blacklist and whitelist

1. Use a blacklist to isolate service access The model for
configuring a blacklist is:
instance: checknothing
handler: denier
rule: configure preconditions, combine denier and checknothing
For example , configure the v3 version service reviews to the blacklist of service ratings

apiVersion: "config.istio.io/v1alpha2"
kind: denier
metadata:
  name: denyreviewsv3handler
spec:
  status:
    code: 7
    message: Not allowed
---
apiVersion: "config.istio.io/v1alpha2"
kind: checknothing
metadata:
  name: denyreviewsv3request
spec:
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: denyreviewsv3
spec:
  match: destination.labels["app"] == "ratings" && source.labels["app"]=="reviews" && source.labels["version"] == "v3"
  actions:
  - handler: denyreviewsv3handler.denier
    instances: [ denyreviewsv3request.checknothing ]

Configure bookinfo-productpage of serviceaccount as a blacklist of service details

apiVersion: "config.istio.io/v1alpha2"
kind: denier
metadata:
  name: denyproductpagehandler
spec:
  status:
    code: 7
    message: Not allowed
---
apiVersion: "config.istio.io/v1alpha2"
kind: checknothing
metadata:
  name: denyproductpagerequest
spec:
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: denyproductpage
spec:
  match: destination.labels["app"] == "details" && source.user == "cluster.local/ns/default/sa/bookinfo-productpage"
  actions:
  - handler: denyproductpagehandler.denier
    instances: [ denyproductpagerequest.checknothing ]

2. Use a whitelist to isolate service access. The model for
configuring a blacklist is:
instance: listentry
handler: listchecker
rule: configure preconditions, combine listentry and listchecker
For example , configure v3 version service reviews to the blacklist of service ratings

apiVersion: config.istio.io/v1alpha2
kind: listentry
metadata:
  name: appversion
spec:
  value: source.labels["version"]
---
apiVersion: config.istio.io/v1alpha2
kind: listchecker
metadata:
  name: whitelist
spec:
  # providerUrl: ordinarily black and white lists are maintained
  # externally and fetched asynchronously using the providerUrl.
  overrides: ["v1", "v2"]  # overrides provide a static list
  blacklist: false
---
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: checkversion
spec:
  match: destination.labels["app"] == "ratings"
  actions:
  - handler: whitelist.listchecker
    instances:
    - appversion.listentry

istio configures inter-service TLS authentication

When installing istio, if TLS authentication is configured, mutual TLS authentication will be enabled for all services managed by istio (services injected with sidecars).
The following display functions are as follows:
1. Enable or disable the service mutual TLS authentication access function on the Kubernetes annotate of the service.
2. Modify the configuration of istio to disable mutual TLS authentication access for some specified control services.

1. Enable or disable the service mutual TLS authentication access function
on the service Add annotation to the service of the istio management service as follows

annotations:
  auth.istio.io/8000: NONE

TLS authentication on port 8000 for this service can be disabled.
2. Modify the configuration of istio to disable the mutual TLS authentication access function for some specified services.
The istio configuration has the mtlsExcludedServices parameter, and add services that need to disable the mutual TLS authentication access function.
For example, disable mutual TLS for service access with kubernetes ApiServer Certification.

kubectl get configmap -n istio-system istio -o yaml | grep mtlsExcludedServices
mtlsExcludedServices: ["kubernetes.default.svc.cluster.local"]

access kubernetes apiserver

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl https://kubernetes.default:443/api/ -k -s
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "104.199.122.14"
    }
  ]
}

Delete mtlsExcludedServices in the configuration and visit again

kubectl get pod $(kubectl get pod -l istio=pilot -n istio-system -o jsonpath={.items..metadata.name}) -n istio-system -o yaml | kubectl replace --force -f -

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl https://kubernetes.default:443/api/ -k -s
command terminated with exit code 35