Istio Mixer Policy

Policies and Telemetry
1

Hi,

Hoping someone might be able to help explain if my findings are correct.

I am trying to create mixer policies to allow/deny services to talk to each other. I.e. if I have 3 services:

service1
service2
service3

I want to initially globally block everything from talking to these services and allow communications from only “allowed” services. So Service 1&2 can communicate but Service 1&3 can’t.

Put simply I wan’t communications to block by default and only allow when explicitly defined with a mixer policy?

Am I missing something?

Cheers.

2

Hi!

If I understand this correctly, you are looking for a white-list behavior for policy rules, where the policy rejects everything by default and only permits certain cases. Unfortunately, this is not possible to express at the level of rules since rules are semantically conjoined with an AND (apply this rule and that rule), where each whitelisted cases requires an OR. Given the current limitation of the rules, the desired behavior should be pushed down into the adapter backend logic. The invocation of the adapter then should be captured with a match condition “true” to capture all cases, and the adapter itself encodes the deny-by-default plus the white-list.

@geeknoid @douglas-reid for more thoughts on the subject.

–kuat

1 Like
3

Hi @kuat,

Thanks for your response. Greatly appreciated. That is exactly what I am trying to do and exactly what I thought to be the case but wanted to check.

Can you share some examples to configuring the adapter backend logic that you mention if it exists?

Cheers,
Dan

4

Kuat is totally right that this kind of semantics must be handled in the adapter proper. For example,the list adapter can operate as either a whitelist or a blacklist for this reason. That use is described here: https://istio.io/docs/tasks/policy-enforcement/denial-and-list/.

6

Hi all,

so I cannot seem to get the policy to work using the listentry template and would appreciate any help with this.

ive got three services with app labels = “$servicename” (svc1, svc2 ,sv3)

i would like comms from svc1 to sv2 and comms from sv3 to svc2 to be denied.

Please see my config below:

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

thanks

7

@Mike_I

From the looks of it, the config looks correct. Can you check the logs of istio-policy and see if you can spot any errors about the config ingestion?

Also, make sure to place the policy in the same namespace as svc1 and svc2 pods. Alternatively, you can use istio-system namespace for global overrides.

8

@kuat, can you not apply policies between namespaces?

Dan

9

Given that we are seeing the following in the Istio-policy logs I would assume that this suggests that Istio-policy is working as expected?

2019-04-09T19:37:42.973462Z info adapters Cache sync successful. {"adapter": "handler.kubernetesenv.istio-system"}

10

You can apply a policy between namespaces if you place it in istio-system. Placement affects scoping of the policy, so that policies in namespace “a” normally don’t interfere with namespace “b”.

The log line you’re seeing is coming from the environmental adapter for k8s which runs before the list checker. Can you confirm there’s nothing about listchecker in the logs for istio-policy?

11

I see this

2019-04-09T19:40:34.510434Z info Publishing 1 events 2019-04-09T19:40:34.512166Z info Built new config.Snapshot: id='19' 2019-04-09T19:40:34.512354Z info adapters Installing updated list with 1 entries {"adapter": "whitelist.listchecker.services"} 2019-04-09T19:40:34.512435Z info adapters getting kubeconfig from: "" {"adapter": "handler.kubernetesenv.istio-system"} 2019-04-09T19:40:34.512482Z warn Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work. 2019-04-09T19:40:34.513408Z info adapters Waiting for kubernetes cache sync... {"adapter": "handler.kubernetesenv.istio-system"} 2019-04-09T19:40:34.613607Z info adapters Cache sync successful. {"adapter": "handler.kubernetesenv.istio-system"}

12

Did you make sure you enabled policy checks per https://istio.io/docs/tasks/policy-enforcement/enabling-policy/ ?