Skip to content
This repository has been archived by the owner on Oct 20, 2023. It is now read-only.

Rename HTTPRoutes HTTPRoute #30

Merged
merged 4 commits into from
May 10, 2019
Merged

Rename HTTPRoutes HTTPRoute #30

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f375f9a
Rename HTTPRoutes HTTPRoute
nicholasjackson May 8, 2019
8f6a88e
Rename HTTPRoutes something more sane
nicholasjackson May 8, 2019
0f1ccc5
update comments for IdentityBinding and ClusterBinding
nicholasjackson May 8, 2019
aaef7d5
Added namespace to allow selection from CRD
nicholasjackson May 9, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions traffic-access-control.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,7 +78,9 @@ connection as well.

A `IdentityBinding` grants access for a specific identity to the rules in a
TrafficTarget. It holds a list of subjects (service accounts for now) and a
reference to the traffic target defining what has been granted.
reference to the traffic target defining what has been granted. The TrafficTarget
which is referenced in targetRef should always be in the same namespace
as the IdentityBinding.

```yaml
kind: IdentityBinding
Expand Down Expand Up @@ -154,7 +156,8 @@ protected label.

A `ClusterIdentityBinding` grants access for a specific identity, originating in
a specific namespace, to a ClusterTrafficTarget associated with pods in any
namespace.
namespace. The ClusterTrafficTarget referenced by targetRef should always be in
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both target and binding aren't namespaced (in my head at least).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha good catch, so the reason I added that is when we are building the CRD and are actually writing the code to read the TrafficTarget, the KubeAPI client requires the object namespace as a parameter.

Originally I added namespace to the TargetRef so that you could do the lookup, then reverted that as IdentityBindings would always be in the same location as TrafficTargets. However, that assumption does not apply for ClusterIdentityBinding.

I think we need to add namespace to the ref then?

---
kind: IdentityBinding
apiVersion: smi-spec.io/v1alpha1
metadata:
  name: account-specific
  namespace: default
subjects:
- kind: ServiceAccount
  name: service-b
  namespace: default
targetRef:
  kind: TrafficTarget
  name: foo 
  namespace: default

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like RoleBinding and ClusterRoleBinding don't need the namespace. I suspect that is because you can only targetRef the cluster or non-cluster resource. I think that targetRef is a custom object there though (and not a ObjectReference). You're in the code so I'll defer to you though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need namespace on everything, it will just make things easier when coding the CRDs no assumptions. I have added this in the latest commit. We can always change things later to make things easier.

the same namespace as the ClusterIdentityBinding.

```yaml
kind: ClusterIdentityBinding
Expand Down
8 changes: 4 additions & 4 deletions traffic-specs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,14 +12,14 @@ to define the traffic in a protocol specific fashion.

## Specification

### HTTPRoutes
### HTTPRouteGroup

This resource is used to describe HTTP/1 and HTTP/2 traffic. It enumerates the
routes that can be served by an application.

```yaml
apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRoutes
kind: HTTPRouteGroup
metadata:
name: the-routes
matches:
Expand Down Expand Up @@ -51,7 +51,7 @@ an HTTP request. This is where `filters` come in:

```yaml
apiVersion: v1beta1
kind: HTTPRoutes
kind: HTTPRouteGroup
metadata:
name: the-routes
namespace: default
Expand Down Expand Up @@ -94,7 +94,7 @@ automatically generate the list of routes from code.
## Out of scope

* gRPC - there should be a gRPC specific traffic spec. As part of the first
version, this has been left out as HTTPRoutes can be used in the interim.
version, this has been left out as HTTPRouteGroup can be used in the interim.

* Arbitrary header filtering - there should be a way to filter based on headers.
This has been left out for now, but the specification should be expanded to
Expand Down