3.9 Release notes
May 13, 2019
Audit and event log exports
Aporeto now supports integration with third-party tools like Kafka for real-time notification of important events. To achieve the integration, you must have an on-premise control plane configured to export the following:
- Audit logs
- Processing unit creation events
- Enforcer creation events
- Flow creation events
Propagation of objects to child namespaces
You can now propagate host services and external networks to all child namespaces as read-only objects.
Audit logging compatible with auditd
Aporeto audit logging no longer requires auditd to be disabled.
Policies for kube-system pods
You can now modify the default enforcer configuration to enforce policies on Kubernetes and OpenShift pods in the
Aporeto enforcer pod security policy
Per service NodePort and Endpoint discovery
You can now configure
Endpoint discovery per Kubernetes or OpenShift service.
As of 3.9, the Aporeto Operator ignores the following flags.
Multiple Aporeto Operators for high availability
As of 3.9, the Aporeto Operator supports leader election, allowing you to deploy multiple Aporeto Operators for high availability.
Enforcer session identifiers
This release of Aporeto reduces the risk of impersonation with enforcer session identifiers (IDs). Each enforcer receives a session ID at the time of registration. It includes its session ID on all requests to the control plane. The control plane rejects requests with mismatched session IDs.
New enforcer runtime role
On-premise enforcers now use a new enforcer runtime role with read-only privileges. The new role removes the need for on-premise enforcers to run with create privileges.
Aporeto custom resource values retrieved from Kubernetes/OpenShift
You can now modify the Aporeto custom resource definitions (CRDs) to retrieve values from a Kubernetes/OpenShift secrets or
Aporeto provides the following additional metadata.
Processing units generated from a host service object now include several new tags identifying their host service object:
Kubernetes and OpenShift pod metadata now includes the pod's service account, replica set, daemonset, and stateful set.
Web interface enhancements
This release of Aporeto includes the ability to define complex expressions to filter views.
The New Service dialog in the web interface has been updated. It now includes an HTTP Header Mapping pane and an Exposed Service is Listening on TLS only check box in the Advanced pane. It also offers the ability to specify a custom certificate authority when authenticating with JSON web tokens (JWT) to support mutual TLS.
After a period of deprecation, the K8s Clusters pane has been removed from the web interface. The Helm install automatically creates Kubernetes cluster objects, removing any need for the K8s Clusters pane.
The AWS Account Bindings pane under Authentication Sources in the Accounts page is deprecated and will be removed in the next release. Aporeto has offered automated AWS account binding since 3.7. For more information, refer to Installing the enforcer on an EC2 instance.
SSH access control (beta)
Aporeto 3.9 allows you to manage and monitor SSH access.
- Single sign-on: Users authenticate to their existing identity provider for a single sign-on experience.
- Local private key: Users generate a public-private key pair locally, sending only the public key over the wire.
- SSH certificate contains identity and other metadata: The Aporeto certificate authority (CA) signs the user's public key, adding the user's identity and other metadata to the certificate.
- Monitor and control SSH access across hosts: The user must use the Aporeto SSH certificate to gain access, providing visibility and control over SSH activities across hosts.
- Certificate revocation: Because the user's certificate is signed by the Aporeto CA, you can revoke it and end their SSH access.
Policy visualization (beta)
The Aporeto web interface includes a new policy visualization view, allowing you to view how the policies you've defined impact traffic that has not yet occurred. The normal view shows only actual traffic.
Policy creation delegation (beta)
Creating a policy that grants access to a namespace no longer requires namespace editor privileges. The namespace editor must approve the policy, but does not have to create it. This allows users desiring access to a namespace to expedite the grant by creating the policy and sending it to the namespace editor for approval. Read more about this in the API reference documentation.