Policy

[nicholasjackson]

Following yesterdays call we discussed the possibility of changing the TLS spec to a higher level Policy spec. Rather than assigned identity, we would have a specification which controls which services are allowed to communicate.

Adding this here to start a discussion, the following example would define a policy which would allow service.a to communicate with service.b and service.c. All other communication would be denied. It is assumed that allow rules would have a higher priority than deny rules, however, this would be based on the concrete implementation.

apiVersion: v1beta1
kind: Policy
name: my-policy
spec:
   allow:
   - source: service.a
     destination: service.b
   - source: service.b
     destination: service.c
   deny:
   - source: *
     destination: *

Questions:

• Should the spec encourage convention to create a consistent user experience, i.e. allow is a higher priority than deny. It could be confusing if two different control planes implemented different conventions.
• Currently the spec is MVP and should be extensible should policy need to consider, http paths, header, verbs, etc. Should this be outlined now or is a mention that this could be extended at a later date.

cc. @grampelberg

[nicholasjackson]

Notes:

• Source and destination should be service accounts
• Could follow the RBAC syntax and rules
• What about the grouping of services (defer decision post-KubeCon)

[grampelberg]

I thought it'd be interesting to see this from the RBAC perspective. The more I think about it, I really like having clients referenced by identity (eg authorizing for them) and servers referenced by logical concept (eg service, deployment, pod, ...).

I need to spend a bunch more time thinking about this, but it feels pretty flexible and makes sense to me at the moment at least.

TrafficRole

These are meant to live inside a namespace, akin to Role. This specific example shows how to do a Role that references a deployment, restricts by method and path (regex).

kind: TrafficRole
apiVersion: v1beta1
metadata:
  name: path-specific
  namespace: default
rules:
- resources:
  - name: foo-775b9cbd88-ntxsl
    namespace: default
    kind: Deployment
  methods:
  - GET
  paths:
  - '/authors/\d+'

TrafficRoleBinding

Roles are bound to different subjects. In this first example, a service account is granted access to the previous TrafficRole.

kind: TrafficRoleBinding
apiVersion: v1beta1
metadata:
  name: account-specific
  namespace: default
subjects:
- kind: ServiceAccount
  name: foo-account
  namespace: default
roleRef:
  kind: TrafficRole
  name: path-specific

For another example, the subject is changed up to reference a deployment instead of a service account.

kind: TrafficRoleBinding
apiVersion: v1beta1
metadata:
  name: account-specific
  namespace: default
subjects:
- kind: Deployment
  name: bar
  namespace: default
roleRef:
  kind: TrafficRole
  name: path-specific

ClusterTrafficRole

Alongside TrafficRole's that are specific and live inside namespaces, it is valuable to define cluster wide roles that can be defaults. This example shows how the cluster can allow everything by default. Take notice of the * kind. It should match everything.

kind: ClusterTrafficRole
apiVersion: v1beta1
metadata:
  name: default-allow
rules:
- resources:
  - kind: *
  methods: ["*"]
  paths: ["*"]

ClusterTrafficRoleBinding

The accompanying binding for ClusterTrafficRoles. Kind is * here as well.

kind: ClusterTrafficRoleBinding
apiVersion: v1beta1
metadata:
  name: default-allow
  namespace: default
subjects:
- kind: *
roleRef:
  kind: ClusterTrafficRole
  name: default-allow

[aanandr]

Had the following 3 comments/suggestions which we can discuss tomorrow

1. We should have a way to make mTLS optional. Istio has it today and is useful. Not sure if we can incorporate this in the first version
2. Policy: while its useful to be able to specify protocol, ports and specific HTTP paths that are allowed i think it will be better to start with a simple policy that only list which services can talk to which other services (with the service account additionally specified for the client). Would this be a better goal for KubeCon or are we confident of pull off TrafficRole and TrafficBinding?
3. It would be really useful to tie the service account with the kubernetes service account and re-use them. Is that already the case?

[grampelberg]

@aanandr great questions! Let me try and give my answers inline. If anything is unclear I'm happy to jump on a call and talk it through =)

We should have a way to make mTLS optional. Istio has it today and is useful. Not sure if we can incorporate this in the first version

I believe that policy without identity (mTLS) is the same as NetworkPolicy. I'm sure there's something I'm missing there though!

better to start with a simple policy that only list which services can talk to which other services

It feels like this is another NetworkPolicy similarity. While SMI 100% should be able to simply define TCP (see TCPService in the current PR), the real benefit to having a service mesh is that you can apply policy above L3/4 and make it application aware. A demo for Kubecon probably doesn't need to tell the entire story, but the spec really should explain why this is better than just using NetworkPolicy.

It would be really useful to tie the service account with the kubernetes service account and re-use them. Is that already the case?

Yup, that's what that is =)

Make sure to check out #16 for some extra details!

[grampelberg]

Initial pass for access control in #16, see #19 for more details.