Memcached Question posted in
A decent usage manual can be found here.

Istio Authorization polices for memcached

I am very new to Istio Authorization policies, I need some help with setting up authorization policies :

Here is the scenario:

  1. I have a namespace called namespace1 which has 4 Microservices running in them. For the context, let’s call them A,B,C,D. And all 4 microservices have istio-sidecar injection enabled.

  2. have a namespace called namespace2 which has 2 Microservices running in them. For the context, let’s call them E,F. And both microservices have istio-sidecar injection enabled.

  3. Now I have deployed Memcached service by following Memcached using mcrouter to namespace memcached. And all the pods of Memcached are also having istio-sidecar injection enabled.

Now I have a scenario where I have to allow only calls from B and C microservices in namespace1 to be made to memcached services and deny calls from A and D in namespace1 along with calls coming from any other namespaces. Is it possible to achieve this using istio authorization policies?

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: authorization-policy-deny-all
 namespace: memcached
spec:
 selector:
   matchLabels:
     app: activator
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["namespace1"]

This is the best I could come up with, where I am allowing only calls from namepsace1 and denying calls from all other namespaces. I could not figure out how I can deny calls from A and D Microservices in namespace1.

Tags:

2

Answers


  1. 0

    You can also use principals for allowing access. As for the example from the Istio documentation on Authorization Policy:

    so analogously something like that should be possible:

     - from:
   - source:
       principals: ["cluster.local/ns/namespace1/sa/B","cluster.local/ns/namespace1/sa/C"]

    According to the doc:

    1. If there are any DENY policies that match the request, deny the request.
2. If there are no ALLOW policies for the workload, allow the request.
3. If any of the ALLOW policies match the request, allow the request.
4. Deny the request.

    So if you have an ALLOW policy for memcached , and allow access from B and C (rule 3), then other requests to memcached from other sources should be denied (rule 2 does not allow access, since you have an ALLOW policy).

    (untested)

    Login or Signup to reply.
  2. 0

    Here’s one setup that might work.

    --- 
spec: 
  selector:
    matchLabels:
      app: activator
  action: ALLOW
  rules: 
    - from: 
        - source: 
            principals: 
              - cluster.local/ns/namespace1/sa/memcached--user
    • B & C to use different service account than the rest of services. Let say the service account name is memcached–user (Depends on the role needed by B & C, you might want to even have separate service account for each service)
    • Define AuthorizationPolicy to allow access from principal which is the service account used by B & C.
    • Make sure mTLS enabled. As stated in the docs, This field (principals) requires mTLS enabled.
    • Make sure selector is configured properly.

    I hope this could solve your issue.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search