As a developer or an operator I want to limit the scope of access to service

[mchmarny]

Assumes identity/role ACL support.

[mchmarny]

Need to define how this relates to:

• Default access across namespaces
• Default access within a single namespace
• How one defines ACL for service
• What is the default authentication/authorization service in this case?

[evankanderson]

I think there are two separate stories here:

1. I want to control who can deploy and run code for my "service" ("Developer", "Releaser", etc role)
2. I want to control who can call my "service" (network endpoint). This is needed for the microservice/function-to-function use case, in addition to 1.

[mchmarny]

Correct, the CUJs will have multiple stories... we should create issue or locate existing ones and reference them under here. (e.g. - [] #34)

[mchmarny]

This epic is about your number 2 (not to link to #2 issue). This is about defining ACL for deployed endpoint. Specifically limiting public access while allowing other apps in my namespace leverage that service (e.g. REST endpoint)

[drewinglis]

I think #34 is actually unrelated to this issue - it's about ACLs for the Github repo/code specifically, not about Elafros permissions...

[tcnghia]

#2127 partially addressed this issue by allow some Route to be excluded from Ingress.

[rgregg]

This sounds like some ability to configure Istio RBAC (or the networking stack) to require authorization as part of the request to the service. Seems like a must have for v1 scope.

[evankanderson]

If we're willing to document the names of the created Istio VirtualServices and require the customer to configure Istio (or whatever their network router is), then something like the following policy configuration for Istio should work; the first object is cluster-wide, the second is namespace-wide, and the last two perform the actual access grant.

This would need to be tested and documented, at a minimum.

apiVersion: rbac.istio.io/v1alpha1
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_EXCLUSION'
  exclusion:
    namespaces: $LIST_OF_NAMESPACES_WITH_NO_RBAC
---
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: mtls-enable
  namespace: $NAMESPACE
spec:
  peers:
  - mtls:
  origins:
  - jwt:
    issuer: $MY_OPENID_PROVIDER
    audiences:
    - $MY_AUDIENCE
    jwtHeaders:
    - authorization
  principalBinding: USE_ORIGIN
---
apiVersion: rbac.istio.io/v1alpha1
kind: ServiceRole
metadata:
  name: $SERVICE-allowed
  namespace: $NAMESPACE
spec:
  rules:
  - services: $VIRTUAL_SERVICE_HOSTNAME
    # Optionally, can add constraints, paths, or methods if desired
---
apiVersion: rbac.istio.io/v1alpha1
kind: ServiceRoleBinding
metadata:
  name $SERVICE-allowed-callers
  namespace: $NAMESPACE
spec:
  roleRef: $SERVICE-allowed
  subjects:
  # Only allow @google.com accounts using Firefox
  # See https://istio.io/docs/reference/config/authorization/constraints-and-properties/#properties for what can be set here.
  - "request.auth.claims[iss]": "*@google.com"
  - "request.headers[User-Agent]": "*Firefox*"

[bakayolo]

FYI, I tried severals times to make mTLS/RBAC working with Knative 0.6.0 without success.
Best test I got is intermittent failures (503) ->

• 3 exacts same services, 2 not working, 1 working
• after redeploy, 3 working but then 5 minutes ago, 1 not working
• etc.

From the many issues that I saw regarding mTLS and Knative, can I assume that Istio mTLS is not yet fully supported?

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[knative-housekeeping-robot]

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

[knative-prow-robot]

@knative-housekeeping-robot: Closing this issue.

In response to this:

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.