|
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:
|
|
|
|
Re: [VOTE] CNCF TOC Principles
Bryan Cantrill <bryan@...>
- Bryan
On Thu, Nov 2, 2017 at 9:00 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
|
|
|
|
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:
|
|
|
|
Call to Action: Project Proposal Due Diligence
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:
|
|
|
|
Re: landscape, spiffe, opa, vault
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 :)
On Wed, Nov 15, 2017 at 11:55 AM, Alexis Richardson <alexis@...> wrote:
|
|
|
|
Re: landscape, spiffe, opa, vault
alexis richardson
On Wed, Nov 15, 2017 at 7:52 PM, Sunil James <sunil@...> wrote:
I am ok with that. Wonder what others think?
Is that an offer? ;-) a
|
|
|
|
Re: landscape, spiffe, opa, vault
Tough one, but I'd say "yes." FWIW, we should probably read through RFC 2989 (specifically the agreed-upon terminology) for historical context.
On Wed, Nov 15, 2017 at 11:32 AM, Alexis Richardson <alexis@...> wrote:
|
|
|
|
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:
|
|
|
|
Re: landscape, spiffe, opa, vault
+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'?
On Wed, Nov 15, 2017 at 8:13 AM, Tim Hinrichs via cncf-toc <cncf-toc@...> wrote:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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.
|
|
|
|
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.
toggle quoted messageShow quoted text
---- Nick
On Wednesday, November 15, 2017, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
|
|
|
|
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.
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.
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.
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.
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.
“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.
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.
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).
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.
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.
-- 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
|
|
|
|
Re: SPIFFE Presentation - TOC Agenda 11/7/2017
Andrew Jessup <andrew@...>
Hi Deepak - great to hear from you! Some answers to your questions inline.
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. 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. 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.
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. “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.
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. 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. 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!
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.
Andrew Jessup | Scyale.io | +1 (347) 855 6187 | Let's meet!
|
|
|
|
Re: CNCF TOC - F2F in Austin
we'll find something for folks who want to take the call F2F too, thanks for the reminder
On Tue, Nov 14, 2017 at 5:56 PM, Alexis Richardson <alexis@...> wrote:
--
Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
|
Re: CNCF TOC - F2F in Austin
alexis richardson
by the same token: do we have a location booked for TOC call on Tuesday Dec 5?
On Tue, Nov 14, 2017 at 12:50 PM, Alexis Richardson <alexis@...> wrote:
|
|
|
