Date   

Re: [RESULT] TOC Principles v1.0 APPROVED

alexis richardson
 

Thank you!


On Mon, 27 Nov 2017, 06:54 Chris Aniszczyk via cncf-toc, <cncf-toc@...> wrote:
Hey all, just letting you know the TOC Principles have been approved:

https://github.com/cncf/toc/blob/master/PRINCIPLES.md

+1 binding TOC votes from:

Alexis: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001382.html
BrianG: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001314.html
Solomon: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001324.html
Jon: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001353.html
Ken: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001354.html
Ben: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001355.html
Camille: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001379.html
Bryan: https://lists.cncf.io/pipermail/cncf-toc/2017-November/001380.html
SamL: https://github.com/cncf/toc/pull/47#issuecomment-344150385

+1 non-binding community votes:


Thanks all!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


[RESULT] TOC Principles v1.0 APPROVED

Chris Aniszczyk
 


Re: [VOTE] CNCF TOC Principles

alexis richardson
 

+1



On Tue, Nov 21, 2017 at 5:21 AM, Erin Boyd via cncf-toc <cncf-toc@...> wrote:
 +1 non-binding

On Mon, Nov 20, 2017 at 6:24 PM, Bryan Cantrill via cncf-toc <cncf-toc@...> wrote:

+1 (And sorry for the delay!)

         - Bryan


On Thu, Nov 2, 2017 at 9:00 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Hey all y'all, the CNCF TOC principles had enough time to bake and are ready for TOC vote:

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] CNCF TOC Principles

Erin Boyd
 

 +1 non-binding

On Mon, Nov 20, 2017 at 6:24 PM, Bryan Cantrill via cncf-toc <cncf-toc@...> wrote:

+1 (And sorry for the delay!)

         - Bryan


On Thu, Nov 2, 2017 at 9:00 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Hey all y'all, the CNCF TOC principles had enough time to bake and are ready for TOC vote:

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] CNCF TOC Principles

Bryan Cantrill <bryan@...>
 


+1 (And sorry for the delay!)

         - Bryan


On Thu, Nov 2, 2017 at 9:00 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Hey all y'all, the CNCF TOC principles had enough time to bake and are ready for TOC vote:

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] CNCF TOC Principles

Camille Fournier
 

+1

On Mon, Nov 13, 2017 at 12:48 PM, Benjamin Hindman via cncf-toc <cncf-toc@...> wrote:
+1

On Mon, Nov 13, 2017 at 9:30 AM Ken Owens via cncf-toc <cncf-toc@...> wrote:
+1 

On Mon, Nov 13, 2017 at 7:47 AM, Jonathan Boulle via cncf-toc <cncf-toc@...> wrote:
+1 from me

On 2 November 2017 at 23:29, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
email is immutable so we stick with that for official voting

thanks Solomon!

On Thu, Nov 2, 2017 at 10:28 PM, Solomon Hykes <solomon.hykes@...> wrote:
+1

Do you want us to approve in github also? Or does email voting remain the source of truth?

On Thursday, November 2, 2017, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Hey all y'all, the CNCF TOC principles had enough time to bake and are ready for TOC vote:

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

All New DC/OS 1.10 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Call to Action: Project Proposal Due Diligence

Chris Aniszczyk
 

Hey CNCF TOC and wider community, we currently have 4 project proposals in flight:


We are asking TOC Contributors (https://github.com/cncf/toc/blob/master/CONTRIBUTORS.md) and the wider CNCF community to do some due diligence on these project proposals. For an example of what we mean by due diligence, please see this PR: https://github.com/cncf/toc/pull/52

Thanks and I look forward to everyone helping out and voicing their opinions.

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: landscape, spiffe, opa, vault

alexis richardson
 

anyone else want to chip in?

On Wed, Nov 15, 2017 at 8:11 PM, Sunil James <sunil@...> wrote:
I've been reading it this morning. I think SPIFFE/SPIRE, OPA, and Vault fit nicely within that framing. Frankly, I think proxies fit within the AAA category, too.

Maybe we're even talking about "AAA" being a new horizontal layer below "Orchestration & Management," within which include the following four (4) categories:

1) Authentication
2) Authorization
3) Key Management
4) Proxies

That said, I'm happy to defer to more thoughtful evaluations :)


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 11:55 AM, Alexis Richardson <alexis@...> wrote:


On Wed, Nov 15, 2017 at 7:52 PM, Sunil James <sunil@...> wrote:
Tough one, but I'd say "yes."

I am ok with that.  Wonder what others think?


 

FWIW, we should probably read through RFC 2989 (specifically the agreed-upon terminology) for historical context.

Is that an offer? ;-)

a
 

---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 11:32 AM, Alexis Richardson <alexis@...> wrote:
would you suggest moving key management to AAA?

On Wed, Nov 15, 2017 at 6:09 PM, Sunil James via cncf-toc <cncf-toc@...> wrote:
+1 to this framing, particularly to its cross-cutting nature. While I agree 'security' is a natural starting bucket, the value propositions these (and other) projects address go beyond this (over time).

Visually, perhaps the TOC should consider a "AAA" box (or something more elegantly worded) to the right (or left) of 'Service Management'?


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc







Re: landscape, spiffe, opa, vault

Sunil James
 

I've been reading it this morning. I think SPIFFE/SPIRE, OPA, and Vault fit nicely within that framing. Frankly, I think proxies fit within the AAA category, too.

Maybe we're even talking about "AAA" being a new horizontal layer below "Orchestration & Management," within which include the following four (4) categories:

1) Authentication
2) Authorization
3) Key Management
4) Proxies

That said, I'm happy to defer to more thoughtful evaluations :)


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 11:55 AM, Alexis Richardson <alexis@...> wrote:


On Wed, Nov 15, 2017 at 7:52 PM, Sunil James <sunil@...> wrote:
Tough one, but I'd say "yes."

I am ok with that.  Wonder what others think?


 

FWIW, we should probably read through RFC 2989 (specifically the agreed-upon terminology) for historical context.

Is that an offer? ;-)

a
 

---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 11:32 AM, Alexis Richardson <alexis@...> wrote:
would you suggest moving key management to AAA?

On Wed, Nov 15, 2017 at 6:09 PM, Sunil James via cncf-toc <cncf-toc@...> wrote:
+1 to this framing, particularly to its cross-cutting nature. While I agree 'security' is a natural starting bucket, the value propositions these (and other) projects address go beyond this (over time).

Visually, perhaps the TOC should consider a "AAA" box (or something more elegantly worded) to the right (or left) of 'Service Management'?


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc






Re: landscape, spiffe, opa, vault

alexis richardson
 



On Wed, Nov 15, 2017 at 7:52 PM, Sunil James <sunil@...> wrote:
Tough one, but I'd say "yes."

I am ok with that.  Wonder what others think?


 

FWIW, we should probably read through RFC 2989 (specifically the agreed-upon terminology) for historical context.

Is that an offer? ;-)

a
 

---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 11:32 AM, Alexis Richardson <alexis@...> wrote:
would you suggest moving key management to AAA?

On Wed, Nov 15, 2017 at 6:09 PM, Sunil James via cncf-toc <cncf-toc@...> wrote:
+1 to this framing, particularly to its cross-cutting nature. While I agree 'security' is a natural starting bucket, the value propositions these (and other) projects address go beyond this (over time).

Visually, perhaps the TOC should consider a "AAA" box (or something more elegantly worded) to the right (or left) of 'Service Management'?


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc





Re: landscape, spiffe, opa, vault

Sunil James
 

Tough one, but I'd say "yes."

FWIW, we should probably read through RFC 2989 (specifically the agreed-upon terminology) for historical context.

---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 11:32 AM, Alexis Richardson <alexis@...> wrote:
would you suggest moving key management to AAA?

On Wed, Nov 15, 2017 at 6:09 PM, Sunil James via cncf-toc <cncf-toc@...> wrote:
+1 to this framing, particularly to its cross-cutting nature. While I agree 'security' is a natural starting bucket, the value propositions these (and other) projects address go beyond this (over time).

Visually, perhaps the TOC should consider a "AAA" box (or something more elegantly worded) to the right (or left) of 'Service Management'?


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




Re: landscape, spiffe, opa, vault

alexis richardson
 

would you suggest moving key management to AAA?

On Wed, Nov 15, 2017 at 6:09 PM, Sunil James via cncf-toc <cncf-toc@...> wrote:
+1 to this framing, particularly to its cross-cutting nature. While I agree 'security' is a natural starting bucket, the value propositions these (and other) projects address go beyond this (over time).

Visually, perhaps the TOC should consider a "AAA" box (or something more elegantly worded) to the right (or left) of 'Service Management'?


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: landscape, spiffe, opa, vault

Sunil James
 

+1 to this framing, particularly to its cross-cutting nature. While I agree 'security' is a natural starting bucket, the value propositions these (and other) projects address go beyond this (over time).

Visually, perhaps the TOC should consider a "AAA" box (or something more elegantly worded) to the right (or left) of 'Service Management'?


---
SJ | sunil@... | Scytale & SPIFFE



On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: landscape, spiffe, opa, vault

Tim Hinrichs
 

+1 to the Authentication (SPIFFE, spire), Authorization (OPA), Audit (?).  Classically these are part of Security, but there's no box for that.  

AAA is typically cross-cutting.  OPA, for example, has integrations with Kube (orchestration), Istio (app), Terraform (provisioning), AWS (cloud).

Tim


On Wed, Nov 15, 2017 at 7:33 AM Guru Chahal via cncf-toc <cncf-toc@...> wrote:
Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: landscape, spiffe, opa, vault

Guru Chahal
 

Similar functions have often been classified as "AAA" in traditional systems (Authentication, Authorization, Accounting). I agree that no box really captures these well today - the closest are likely 'coordination and service discover' or perhaps 'service management'. I'd imagine 'service management' is the the likely best current home... Istio is listed there as well today (most adjacent to these projects today). 

-Guru


On Wed, Nov 15, 2017 at 6:59 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: landscape, spiffe, opa, vault

alexis richardson
 

That was where I was going...

Do others agree?


On Wed, Nov 15, 2017 at 2:58 PM, Nick Chase <nchase@...> wrote:
I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a




Re: landscape, spiffe, opa, vault

Nick Chase
 

I think OPA belongs in the top layer but I don't think it fits in any of the existing subcategories.  In fact I feel that way about all three.

---- Nick


On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a



landscape, spiffe, opa, vault

alexis richardson
 

All,

Question about the landscape.


- do we want to put OPA in the top layer, either inside, or next to App Def?
- what about identity - spiffe and spire?
- do we think key management should move to top layer?

a



Re: SPIFFE Presentation - TOC Agenda 11/7/2017

Deepak Vij
 

Thanks Andrew, I really appreciate your detail answers to my questions I raised earlier. Let me digest all these details and get back to you in case I need more clarity etc. In the meanwhile, thanks again.

 

Regards,

Deepak Vij

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Andrew Jessup via cncf-toc
Sent: Tuesday, November 14, 2017 7:33 AM
To: cncf-toc@...
Subject: Re: [cncf-toc] SPIFFE Presentation - TOC Agenda 11/7/2017

 

Hi Deepak - great to hear from you! Some answers to your questions inline.

 

---------- Forwarded message ---------
From: Alexis Richardson via cncf-toc <cncf-toc@...>
Date: Sun, Nov 12, 2017 at 12:52 PM
Subject: Re: [cncf-toc] SPIFFE Presentation - TOC Agenda 11/7/2017
To: Deepak Vij (A) <deepak.vij@...>
Cc: cncf-toc@... <cncf-toc@...>

 

Thank you for posting questions Deepak!

 

On Sun, 12 Nov 2017, 20:32 Deepak Vij (A) via cncf-toc, <cncf-toc@...> wrote:

Hi all, this is regarding the recent CNCF TOC meeting last week, specifically related to the SPIFFE presentation during the meeting. I saw most of the presentation but missed some of it at the end. It would be really great if there is recording available for this session which I could view.

 

Now coming back to SPIFFE, I am really interested in finding out more about it. After the TOC meeting, I did some research on it by going through the content on SPIFFE SIG web page and few other related documents. Based on my initial cursory look at it, I have following questions for gentleman who presented SPIFFE during the meeting:

·       Based on my understanding, SPIFFE is a set of specifications and SPIRE is the actual one of the reference implementation for the SPIFFE specs. Based on my initial research, it seems Istio Service Mesh project has its own implementation which is SPIFFE compliant.

Istio has implemented the X.509-SVID as its identity token. This is part of the SPIFFE specification. We’re working closely with the Istio team (and others) to align on a joint full specification. More on this below.

The fact SPIFFE/SPIRE and Istio are aspiring to be viable CNCF projects, are these two distinct SPIFFE implementations going to merge down the road or is it to do with the fact that domain of Istio service mesh is service-to-service authentication at the intra K8S cluster level versus SPIFFE/SPIRE strives to go beyond intra service-to-service authentication and additionally provide support for external services access as well?

I'd say it's fair to say that Istio is one very powerful application of the principles behind SPIFFE, but not the only one. Both projects aim to solve for identity beyond Kubernetes and are thus conceptually aligned. The near term goal for both projects is to align on a common specification, such that either implementation could form the basis of an Istio implementation. Our long term goal is to merge implementations. SPIRE will remain independent, regardless of whether the long term goal is reached or not.

·       Also, I noticed that currently SPIFFE Verifiable Identity Document (SVID) provides support for only X.509 format. Are there plans to provide support for SVID types such as JWT down the road. Or is it by design that only X.509 format is supported because of vulnerabilities of JWT (masquerading, playback attacks etc.) and X.509 is the only viable format which does not have all these vulnerabilities at the present time.

The SPIFFE specifications have been explicitly structured in a manner to support multiple SVID formats in the future.  Indeed the "JWT-SVID" is something the SPIFFE community has been investigating. We recognize the limitations and shortcomings of an X.509-based SVID, and seek to address at least a subset of those use cases with the introduction of a JWT-SVID. Namely, we seek to decouple identity from transport. Work in this area is ongoing.

 

Our main motivation to initially support X.509 was that multiple mTLS libraries can support it with little modification, and SVIDs could thus be used to establish mTLS. Many JWT signing and verification libraries also accept X.509 certificates, meaning applications that prefer to use JWT tokens to assert specific claims could, in principle, use X509-SVIDs to do so.

 

Although, I recently saw a proposal in Kubernetes AUTH SIG “Trustworthy Workload JWTs” for addressing all the known issues with JWTs. Provided all the current JWT issues are sorted out (adding nonce to prevent replay attacks etc. etc.), do we see JWT as a viable SVID format type down the road? Also, from backward compatibility perspectives, Kubernetes Service Account Identity is currently JWT token based.

If this topic interest you, we’d love to speak further to learn about your use-case, and how SPIFFE could help. I’d also recommend getting involved in the SPIFFE Specifications SIG which has an active Slack channel. 

·       Currently in Kubernetes, identity is defined at the Service level, is the intent of SPIFFE to provide more granular identity at the actual workload level (Pods, Containers or possibly native UNIX Process level)? The SPIFFE demo I recently saw includes identity attestation for native Unix process (database running as a process), in addition to K8S Pod.

“Yes” is the short answer here :) The longer answer is; the definition of what constitutes a given workload (and thus should be assigned a given identity) will vary between organizations, platforms, and projects and so we support a flexible "attestation policy" framework to allow folks to define identity in a manner that makes sense to them. 

 

An attestation policy describes conditions (such as “is member of an AWS instance in a given security group” and/or “has given process ID” and/or “is associated with a given Kubernetes service account”) that SPIRE must verify before issuing an identity. Evan Gillman gave a demo recently of this capability to the k8s SIG-Auth, showing how SPIRE can issue identities based on k8s-speciifc constructs such as namespace or service account.


The goal of the SPIRE project, via a range of plug-ins, is to provide a rich and extensible language for this attestation policy that can be used to reliably identify a wide range of workloads in heterogeneous computing environments. Notably, since SPIRE supports attestation based on infrastructure as well as workload, it can be used to issue identities accross different Kubernetes clusters, as well as non-Kubernetes based workloads within the same identity namespace.

 

·       Why not implement OpenID Connect based identity provider within Kubernetes cluster instead of re-inventing the wheel. I am assuming this may be due to well-known JWT vulnerability related issues as mentioned before. Also, external OIDC implementation does have problems related to network round tripping.

As you note, unlike oAuth related protocols (including OIDC), the X509-SVIDs and corresponding private keys don’t need to be issued for each connection, and have a tunable TTL. This has a few tactical advantages, including (a) faster time to establish a connection than if each connection needed to to be negotiated independently with a round trip to a trust broker, and (b) any system that relies upon them to establish connections is more resilient in the event of any transient failures of the SPIRE service.

 

Beyond this, I’ll confess to having only passing familiarity with OIDC, but from a cursory look at the documentation - to a certain extent, it seems these are solving related but different problems.

OIDC seems to primarily care about negotiating trust and authorization between two parties where trust has already been established to a third-party (which can act as a broker). This pre-establishment of trust is often using a pre-shared secret, but could be performed in many ways (including via SPIFFE/SPIRE, conceivably). SPIFFE/SPIRE don't reason at all about authorization.

·       Also, I noticed that SPIFFE design aspires to be decentralized versus SPOF issues for OpenID Connect type identity providers. Can’t SPOF issue of OIDCs be addressed by implementing redundant or back-up Identity Providers. Although, this does increase the complexity of the overall solution. Based on my understanding SPIFFE design consists of Node (at the Node level) & Server Agents (at the Master API Server level) components. Initially when I saw decentralized design of SPIFFE I thought it was peer-to-peer based trust model approach, there has been lot of research on P2P trust model in the academia but I have not seen that in practice yet.

While SPIRE does have a client-server architecture, it isn’t designed to be fully decentralized, or to eliminate SPOF (though this can be mitigated by increasing the TTL of the identities issued, and a HA mode is in the works). SPIFFE/SPIRE does expressly support the ability to carve infrastructure into multiple “trust domains” to mitigate the “blast radius” of a faulty or compromised SPIRE control plane. And as noted above, longer lived X509-SVIDs can add resiliency in the event of an outage of SPIRE (at the expense of a wider impact should the key be stolen).

Additionally, a fully P2P-based SPIFFE implementation is conceivable here, too, though not on the near-term roadmap. If you see value here, let’s chat!

·       Lastly, how does this all play out in the enterprise SAML based federated identity environment (good old WS-Security, WS-Trust stuff). How are the legacy coarse grained SOA Web Services going to play out in the SPIFFE like environment. The reason I bring all this up is because legacy enterprise SOA based web services are still going to be there as coarse grain services side-by-side with the newer micro-services architecture.

 

Great question. There are multiple ways to practically solve this problem, but some form of identity and protocol translation is likely necessary to guarantee interoperability. SPIFFE and SPIRE themselves don’t aim to solve for this problem, but should be considered as the foundation for tools that do.

A likely path here is that if each legacy workload can be identified with a SPIFFE ID by SPIRE, an agent could then map that SPIFFE ID to a legacy token, and then act as an exchange between the two. Some secrets management tools already perform this function to some extent, and we hope to see some of them support SPIFFE directly over time. 

 

I am sure as I understand more about SPIFFE, I will have lot of follow up questions. In the meanwhile, it would be good to get the fog cleared up in my mind based on my initial understanding of all this. But overall, SPIFFE definitely seems to be a step in the right direction and I am really interested in this effort going forward. Look forward to your response on all this. Thanks.

 

Always great to hear thoughtful questions about SPIFFE. Hope these answers helped! I’d encourage you to get involved in the SPIFFE community (Slack is a great place to start). Feel free to contact me directly if you’d like some time to go through it.

 

 

Regards,

Deepak Vij   

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, November 06, 2017 12:31 PM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] TOC Agenda 11/7/2017

 

Hey all, we have a TOC meeting tomorrow, here's the agenda deck: https://goo.gl/LoKyV5

 

We will be hearing from the Istio and SPIFFE projects, along with getting a brief update from the Serverless WG.

 

See everyone tomorrow!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



 

--

Andrew Jessup | Scyale.io | +1 (347) 855 6187 | Let's meet!


Open Policy Agent

Torin Sandall
 

Hello!

Here are extra materials that were requested on the call.

You can find out more about OPA at openpolicyagent.org. We have a number of tutorials with examples across Kubernetes, Terraform, SSH, etc:


Here are two examples that show how you can write high-level declarative policies in OPA for different use cases like authorization and workload placement.

# REST API authorization example.

# First rule allows employees to GET their own salary.
# This rule shows how you can use variables in rules. In this case, employee_id
# is a variable that will be bound to the same value across the last two expressions.
allow {
    input.method = "GET"
    input.path = ["salary", employee_id]
    input.user = employee_id
}


# Second rule allows employees to GET the salary of their reports (transitively).
# This rule uses data/context loaded into OPA (data.management_chain). For example,
# the data may be organized as {"management_chain": {<employee_id>: [<mgr1>, <mgr2>, ...]}}
allow {
    input.method = "GET"
    input.path = ["salary", employee_id]
    input.user = data.management_chain[employee_id][_]
}


# Cluster placement example. In this case, the input would be an object representing
# a workload (or part of a workload, e.g., a Kubernetes Deployment.)

# First rule generates a set of clusters to place a workload on.
# This rule shows how you compose rules/functions.
desired_clusters = {name |
cluster = data.clusters[name]
satisfies_jurisdiction(input.deployment, cluster)
}

# This rule decides whether a cluster satisfies the deployment's jurisdiction requirements.
satisfies_jursidiction(deployment, cluster) {
deployment.jurisdiction = "europe"
startswith(cluster.region, "eu")
} else {
not deployment.jurisdiction
}

As Tristan mentioned on the call, OPA can also ingest and evaluate configuration like RBAC rules. This is what Istio is planning to do. The benefit of this approach is that it provides a simple interface for administrators, but at the same time, if they need to tweak or extend the policy, they can do so by dropping down to the lower level policy language. They do not have to modify the policy engine itself.

-Torin

5961 - 5980 of 7342