TAP 1.6 – App Live View Improvements

TAP 1.6 – App Live View Improvements One of the great features in TAP Developer Portal (previously TAP GUI) since the initial release, has been the app live view plugin, which can help visualize actuator data from spring based java applications as well as steeltoe based dotnet core applications. In TAP 1.6, Application Live View (ALV) has been enhanced with 2 key new features Per User RBAC for secure access to sensitive operations Spring native support Lets dig a bit into each of these enhancements and see what is in store for us in this release! Per User RBAC for sensitive operations In TAP 1.5, the ALV components were enhanced to add in an additional layer of security around exposure of accelerator data. While actuator data can be extremely helpful when debugging or simply monitoring an application, depending on the settings you have configured, for which actuator endpoints to expose, it can also be a security risk to have such powerful access to manipulate an application live through Tanzu Developer Portal (TDP). ALV now has split the endpoints exposed into the regular actuator endpoints and the “sensitive” endpoints. this seperation allows for what was made the default in TAP 1.5, which is that only non-sensitive endpoints are visualized in TDP by default. While this is great from a security perspective, we loose out by default from having the ability to run actions that may be extremely helpful such as downloading a heap dump or thread dump, or changing the log levels on a live running pod. With TAP 1.6, we can now not only toggle this setting like in TAP 1.5 to allow or disable sensitive endpoints, but we can actually allow this feature for a subset of users, while denying it for the rest of our user base. This is done via standard kubernetes RBAC resources, using a custom resource and verb pairing: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: alv-execute-sensitive-op-role rules: - apiGroups: ['appliveview.apps.tanzu.vmware.com'] resources: - sensitiveoperationsaccesses verbs: ['execute'] With that Cluster Role applied to you cluster you can start creating role bindings for specific users to utilize this role as such: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: scott-alv-admin namespace: dev-team-1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: alv-execute-sensitive-op-role subjects: - kind: User name: "scott@vrabbi.cloud" apiGroup: rbac.authorization.k8s.io While this is a great feature, to gain full usage of it, and really see the benefits, you must have a very specific setup. By default in TAP, access to the kubernetes clusters from the UI, is performed by using a shared service account token which is placed in your TAP values file. If this were to be how you configured your environment, the setting mentioned above, does not help very much, as all users once logged into the TDP, will use the same credentials to access the cluster. With that said, TAP provides us with the ability to use per user authorization to the kubernetes clusters, however this does require using the same OIDC provider for your cluster as well as for TDP itself. This method is documented for GKE and for EKS, however it should be possible to get it to work with other kubernetes distributions as well, as long as the same OIDC client setup is used for both the cluster and TDP. Spring Native Support The other new feature in ALV in TAP 1.6 is support for native compiled Spring based applications. Spring native apps, are becoming a really popular and paradigm shifting topology organizations are starting to adopt. While not all apps can be compiled today to spring native, due to either dependencies which are not compatible yet, or simply some internal logic which doesn’t support it within your own code, the ability to compile your app into native machine code, with a lightweight JVM replacement via GraalVM, and then being able to save magnitudes of memory and CPU usage, as well as much shorter startup times, makes using Java so much more practical, and powerful, when dealing with micro services and other cloud native architectures, in which size and performance, and speed of startup truly are the name of the game. While native apps are now supported in TAP 1.6 within ALV, it is important to note that not all actuator endpoints are available yet. I’m sure that with future releases, more and more endpoints will be integrated into ALV, making the experience even better than it is right now!