How to leverage the Netcentric AC Tool with AEM as a Cloud Service

Adobe recently released its innovative AEM as a Cloud Service. While there aren’t many changes on the development side[1], the underlying infrastructure and the way in which it operates is fundamentally different. Unlike the old service, the cloud-native AEM runs on docker containers on k8s. Because of this changed server topology, the way in which the AC tool is triggered in the cloud has been completely rethought. 

With AEM as a Cloud Service, the traditional way to use an Install Hook on the content package containing the yaml files no longer works. With the new service, there is no package installation onto existing instances. Instead, immutable containers are built from scratch using the Sling Feature Model [2]. Those immutable containers only contain the paths /apps and /libs using the Jackrabbit Oak Composite NodeStore [3].

With the Composite NodeStore, the paths /apps and /libs are read-only when running against actual content. Because of this, the AC Tool has to run once when /apps and /libs are created (during creation of the container) and once when the container is started against the actual content of an instance. As part of the new system, a Startup Hook has been introduced that triggers the AC Tool on startup. The startup hook runs on start level 27 (the stage when all packages are deployed), just before the system’s ready checks report that the instance is ready:

1. Container Image Build: This is a regular instance where /apps and /libs are still writable. This run creates the correct ACLs in /apps and /libs. It will also create users/groups in /home and ACLs in /content or /conf if those paths exist. However, only the changes in /apps and /libs become active when the container runs in the composite NodeStore. In Cloud Manager, the log for “Build Images” will contain the AC Tool logs of this execution.
2. Container Deployment: For this case, the instance runs with the Composite NodeStore and /apps and /libs in an existing container that is read-only. The AC Tool won’t make changes to those paths anymore and automatically discards them. Container Deployment typically happens when a new software version is deployed by k8s, but it will also occur when new containers are added due to auto-scaling. In order to avoid unnecessary load, the Startup Hook creates a hash over the yaml configuration files and only runs if that hash has changed. In Cloud Manager, the deployment log will contain the AC Tool logs of this execution for author. Logs of execution for publish can be found in regular instance logs.

For further information about the Startup Hook, see the documentation [4].

With AEM as a Cloud Service, the Apache Felix system console is not directly available but wrapped in a read-only developer console (currently, this cannot contain custom functionality and runs on its own node). To make the AC Tool  accessible in the Cloud, a new Touch UI interface has been created:

While the change outlined in [1] might require some alterations in your application, to leverage the AC Tool you just need to upgrade to the latest version (2.5.1 [5] at the time of writing). However, it’s important to note that if you previously installed the AC Tool manually, you’ll need to ensure that you’ve included the AC tool in a third-party package in your software. (In non-cloud systems, this is usually already set-up.)

For local development with the SDK we recommend that you leave the package install hook in. (This is also good practice as it means keeping a package dependency from the config package with the AC Tool software package). With this setup locally the package install hook will run. In the Cloud, the startup hook will become active automatically without additional configuration. 

In most cases, if you are migrating to AEMaaCS, you’ll want to use Adobe IMS. It’s easy to reference Adobe IMS groups with the “isMemberOf” property of ACE definitions in your yaml files. IMS groups are created per environment and assignments can be made based on the AEMaaCS runmodes “dev“, “stage“ and “prod“.

References

[1] https://docs.adobe.com/content/help/en/experience-manager-cloud-service/release-notes/aem-cloud-changes.html

[2] https://sling.apache.org/documentation/development/feature-model.html

[3] https://jackrabbit.apache.org/oak/docs/nodestore/compositens.html

[4] https://github.com/Netcentric/accesscontroltool/blob/develop/docs/ApplyConfig.md#aem-as-a-cloud-servic

[5] https://github.com/Netcentric/accesscontroltool/releases/tag/2.5.1