Istio Configuration

Sidecar Configuration

The sidecar configuration can be set per service/app to fit its specific enforcement requirements. The sidecar configuration is done by custom resource definitions that are part of the installation process. To apply the configuration, run the following command:

kubectl apply -f authz-v1-plainid-injector.yaml

The configuration will be applied immediately and no redeployment of the application is required.

Custom Resource Definitions

Sample authz-v1-plainidinjector.yaml

apiVersion: authz.plainid.io/v1
kind: PlainidInjector
metadata:
  name: plainidinjector-sample
spec:
  volume:
    name: podinfo
    downwardAPI:
      items:
        - path: "labels"
          fieldRef:
            fieldPath: metadata.labels
        - path: "annotations"
          fieldRef:
            fieldPath: metadata.annotations
 
  container:
    name: plainid-authz
    image: gcr.io/plainid-presales/authz-envoy-sidecar:1.0.1
    resources:
      requests:
        cpu: "0.05"
        memory: "50M"
      limits:
        cpu: "0.2"
    imagePullPolicy: Always
    ports:
      - containerPort: 50051
      - containerPort: 9090
    volumeMounts:
      - name: podinfo
        mountPath: /config
    env:
      - name: POD_NAME
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: metadata.name
      - name: POD_NAMESPACE
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: metadata.namespace
  config:
    params:
      mgr: plainid-controller-manager-discover.plainid-system:16000
      SKIP_TLS_VERIFY: "true"

authz-v1-plainidinjector.yaml

The following table lists the keys that should be updated in the plainidinjectorconfig.yaml.
All remaining text should be the default value.

PlainidSidecar

The PlainidSidecar CRD provides a mechanism to customize the Sidecar configuration generated by the operator. Use the PlainidSidecar CRD to modify values for certain fields and define the specific behavior of the Sidecar.
*Note: This feature must be used with care, as incorrect configurations could potentially destabilize the Sidecar and the service. *
Apply configuration by workload selectors and namespaces. The following example applies to all workloads with the label app:echo in a namespace test.

Sample sidecar-echo.yaml

Following is an example of a microservice sidecar configuration file.

apiVersion: authz.plainid.io/v1
kind: PlainidSidecar
metadata:
  name: echo
spec:
  workloadSelector:
    labels:
      app: echo
  sidecarConfig:
    matchers:               # API Matchers section (Optional)
      - match: /echo/bypass# Request path pattern
        method:            # Request methods
          - POST
          - GET
        bypass: true       # Bypass request (ignore all validations and authorization) 
      - match: /echo/:abc
        runtime:           # Specific runtime configuratoin for matching requests 
          entityTypeid: jwt
          cacheTime: 11s
        mode:              # Specific mode configuratoin for matching requests
          entitlement: true
          format: 5
          flat: false
          denyOnEmpty: true
      - match: /echo
        runtime:
          metadata: "{\"combinedMultiValues\": true}"
          entityTypeid: jwt
          cacheTime: 11s
          clientId: client_id_goes_here
          clientSecret: client_secret_goes_here 
          environments:
            amount: "$.body.amount"
            account: "$.body.account"
            url: $.path.[0]
        mode:
          resolution: true
          format: 5
          flat: false
          denyOnEmpty: true
    runtime:
      clientId: client_id_goes_here           # Mandatory: From the Platform UI
      clientSecret: client_secret_goes_here   # From the Platform UI, if no Secret store used 
      entityTypeid: jwt
      plainidUrl: https://demo.plainid.cloud  # Mandatory: PDP URL, Should be set
      resourceTypes:                          # Asset mappings example (only for PDP API v1-4)
        - name: Accounts
          assetPath: $.path[4]
        - name: Loans
      environments:
        amount: "$.body.amount"
        account: "$.path[2]"
        url: $.path.[0]
    jwt:                                      # Mandatory: External request JWT configuration
      header: authorization
      allowed:
        - name: demo.plainid.cloud            # Mandatory: JWT Issuer example
        - name: demo                          # Mandatory: JWT Issuer mapping example in case of JWT issuer do not match an issuer provided by Auth service
          mapped: https://demo.plainid.cloud/auth/realms/demo
      userClaim: "$.user.preferred_username[0]"
      validateJwt: true
      algs:              # List of supported Signing Algorythms (RS256 by default if not set)
        - ES256
        - RS256
    mode:                # Mandatory: Operation mode, ONLY ONE OF SHOULD BE TRUE: decision/entitlement/resolution/denyOnEmpty
      decision: true     # PERMIT/DENY Mode
      entitlement: false # Header Injection mode
      resolution: false  # Header injection mode Query format
      denyOnEmpty: false # DENY transaction when no policy fits the access request.
      format: 2
    logger:
      logLevel: debug
      detailedLog: false
      format: text
    tlsSkip: true
    grpc:
      servicePort: "7001"

sidecar-echo.yaml

ResourceTypes

Request Parts Locations

Operation Modes

The Platform sidecar supports three operation modes:

• Decision – a basic Permit/Deny mode that enables or blocks the transaction.
• Entitlements – an advanced mode that can enrich the request header with a list of entitlements or any authorization supporting data.
• Resolution – an advanced mode that can enrich the request header with a “policy resolution” decision - JSON or SQL filtering for data.

For more information on these options, refer to the Authorization APIs in the Developer Portal.

Request Sample

Mapping Sample

Additional Configuration Information

:::

Override Default Configuration

The helm install command accepts parameters to override default configuration values inline or that are defined in a file.

1. Example – To override the configuration found in the file:

cat override-values.yml

runtime:
  debugLevel: info
  replicas: 5

helm install sidecar-test1 ./ --values override-values.yml

2. Add a namespace label to instruct PlainID to automatically inject the sidecar when you deploy your application later:

kubectl label namespace default pid-injection=enabled

3. Instruct the Istio proxy to send the traffic to the PlainID sidecar for authorization.

The following example (found in filter.yaml) inserts an http ext_authz filter in the default namespace:

apiVersion: v1
items:
  - apiVersion: networking.istio.io/v1alpha3
    kind: EnvoyFilter
    metadata:
      generation: 1
      name: demo-filter
      namespace: default
    spec:
      configPatches:
        - applyTo: HTTP_FILTER
          
            match:
            context: SIDECAR_INBOUND
            listener:
              filterChain:
                filter:
                  name: envoy.http_connection_manager
                  subFilter:
                    name: envoy.router
              portNumber: 7000
          patch:
            operation: INSERT_BEFORE
            value:
              name: envoy.ext_authz
              typed_config:
                '@type': type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
                failure_mode_allow: false
                grpc_service:
                  google_grpc:
                    stat_prefix: ext_authz
                    target_uri: 127.0.0.1:50051
                  timeout: 2s
                transport_api_version: V3
                with_request_body:
                  allow_partial_message: true
                  max_request_bytes: 1024
                  pack_as_bytes: true
#    workloadSelector:
#      annotations:
#        plainid.io/inject: "yes"
kind: List
metadata:
  resourceVersion: ""
  selfLink: "" 

Sample values.yaml

Note: For versions 4.x, you should remove the following from the values.yaml configuration file:

pdpAPIVersion: v5 #Optional: PDP Runtime API v5 integration

# Please Generate  Public key , Private key and  Certificate chain
# based on the documentation provided by PlainID and place in certs folder
# File names should match the example files  in the chart
 
image:
  pullPolicy: Always
imagePullSecrets:
  - name: cr-creds
nameOverride: ""
fullnameOverride: ""
serviceAccount: plainid
podSecurityContext: {}
operator:
  image: gcr.io/plainid-presales/authz-operator
  namespace: plainid-system
  resources:
    limits:
      cpu: 100m
      memory: 100Mi
    requests:
      cpu: 100m
      memory: 20Mi
  replicas: 1
  debug: true
redis:
  local: true
  image: redis
  port: 6379
  pass: ""
  tls: false
  masterhost: test-plainid-redis-ro.plainid    # Administration point address
securityContext:
  capabilities:
    drop:
      - ALL
  runAsNonRoot: true
  runAsUser: 1000610001
webhook:
  enabled: true
  selfCert: true
auth:                                         # Optional: Secret store configuration
  file: "/keys/key"
  iss: "ruleengine"
  exp: 10s
pdpAPIVersion: v5                            #Optional: PDP Runtime API v5 integration
authorizer:
  id: test-authorizer                         # Mandatory: Should be updated
  version: 1.2.3
moreVolumes:                                  # Optional: Extra volumes configuration
  - name: key-config
    configMap:
      name: key-config
nodeSelector: {}
tolerations: []
affinity: {}

authz-v1-plainidinjector.yaml

The following table lists the keys that should be updated in the plainidinjectorconfig.yaml.

All remaining text should be the default value.

Operator

Redis

Auth

GRPC Support

The PlainID sidecar supports GRPC (Google Remote Procedure Call) parsing. This capability can be achieved in different ways:

• Auto learning
• Providing a Protocol Buffer (protobuf) descriptor file

Auto Learning

To support auto learning, the Application Developer should be enabled GRPC reflection on the server side (backend). In the sidecar configuration YAML, the service port should be defined. Example

grpc:
     servicePort: "7001"

Providing a protobuf Descriptor File

Providing a protobuf descriptor file can be accomplished in one of the following ways:

Multiple Descriptors

It is possible to include multiple descriptors. You can use the same image for all the services. To use the same image for multiple descriptors:

1. Change the PlainidInjector yaml to provide a new image tag.
2. In the plainidsidecar.yaml file, provide the path to the relevant descriptor file.

grpc: protoFile: "/proto/demo.pb"