Data Protection Working Group

[xing-yang]

This PR proposes to form a Data Protection Working Group. This is a cross SIG collaboration between SIG-Apps and SIG-Storage.

Discussed at SIG-Apps and SIG-Storage meetings and proposed in the mailing list:
https://groups.google.com/forum/#!topic/kubernetes-dev/0ZWLfML3uS0

committee/steering
Approvers: @saad-ali @prydonius

[xing-yang]

/hold

[nikhita]

/committee steering

cc @kubernetes/steering-committee

[prydonius]

charter lgtm

[yuxiangqian]

cc @jingxu97

[yuxiangqian]

cc @alarge

[xing-yang]

cc @liyinan926

[spiffxp]

LGTM from steering member, need three more

[dims]

LGTM from me (any nits from me are not blocking)

[timothysc]

/assign @timothysc

[xing-yang]

I am okay with SIG Auth not being explicitly listed as a stakeholder here (though I would like opinions from the other tech leads). We try to avoid being SIG "Security" since everything has some security aspect.

Thanks @enj. Either way I'm open to suggestions from SIG Auth leads.

[xing-yang]

Talked to @deads2k and he thinks that SIG-Auth does not need to be an endorsing SIG, but the WG will need to engage to some degree with SIG-Auth.

So I removed SIG Auth as an endorsing SIG and stated that we will consult SIG Auth from security aspects.

[tallclair]

It seems like the main focus of this working group is around backup and restore (as @mikedanese mentioned, I was expecting more of a policy & compliance angle). If that is indeed the focus, can you explain why this needs to be a working group, and isn't just a subproject of SIG-Storage?

If the policy aspects are within scope, then you should also sync up with the policy working group and CNCF SIG-Security, which are looking at similar issues.

[xing-yang]

It seems like the main focus of this working group is around backup and restore (as @mikedanese mentioned, I was expecting more of a policy & compliance angle). If that is indeed the focus, can you explain why this needs to be a working group, and isn't just a subproject of SIG-Storage?

If the policy aspects are within scope, then you should also sync up with the policy working group and CNCF SIG-Security, which are looking at similar issues.

Hi @tallclair, this WG is looking at things from SIG-Apps angle as well, not just within SIG-Storage scope.

[nrb]

If that is indeed the focus, can you explain why this needs to be a working group, and isn't just a subproject of SIG-Storage?

@tallclair From my conversations around this, I believe the reasoning includes (but isn't limited to) the following topics, which I think this document should mention explicitly:

• How are application representations inside the Kubernetes API server/etcd backed up and restored? I work on Velero, which has one approach to this, but there's also the Stateful Application Data Management API KEP
• How is application quiescing handled before and after snapshots? This is something sig-storage has deferred to sig-apps on as I understand, with work such as ExecutionHooks

[mikedanese]

I am okay with SIG Auth not being explicitly listed as a stakeholder here (though I would like opinions from the other tech leads). We try to avoid being SIG "Security" since everything has some security aspect.

I agree with this assessment.

[timothysc]

minor comments, otherwise
/lgtm

[xing-yang]

/hold cancel

[xing-yang]

Rebased.

[dims]

/approve

[timothysc]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, timothysc, xing-yang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dims,timothysc]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[derekwaynecarr]

i had been out of office, but for posterity, this is lgtm

/lgtm

[xing-yang]

Thanks everyone!