Skip to main content
Cloud Foundry is an application platform. It runs as open-source Cloud Foundry, as VMware Tanzu Application Service and as the SAP BTP Cloud Foundry environment. Connect a foundation to Oleria to bring its people and machine identities, the org and space roles they hold, the resources those roles reach, and the Cloud Controller audit trail into your identity and access graph.

​
What Oleria discovers

  • User accounts:
    • username, email and identity provider (origin);
    • whether they sign in through single sign-on;
    • their highest role.
    • With the optional UAA scopes below, also user status, name, last sign-in and last password change.
  • Machine identities:
    • UAA clients that hold org or space roles; with clients.read, every UAA client, its client secret as a credential, and the user who created it;
    • service keys, with their credential and the user who created them.
  • Organizations, spaces, apps and service instances, and how they contain each other.
  • Org and space roles:
    • every Org Manager, Org Auditor, Org Billing Manager, Org User, Space Manager, Space Developer, Space Supporter and Space Auditor assignment;
    • the access each role grants on its org or space.
    • Org Managers are also shown with read access to every space in their org.
  • Foundation administrators:
    • With UAA access, members of the cloud_controller.admin, cloud_controller.admin_read_only and cloud_controller.global_auditor groups, and the other UAA groups.
    • Without UAA access, as on SAP BTP, a Cloud Foundry Platform Admins (synthesized) group marks that foundation-wide admins exist, because Cloud Foundry does not list them with the org and space roles.
  • Cloud Controller audit events: role grants and removals, service key creation, reads and deletion, app environment reads, cf ssh access, and the lifecycle of orgs, spaces, apps and services.
Oleria uses this data for access reviews, NHI discovery and user profile inventory. It syncs on Oleria’s regular sync schedule.
Sign-in and password events are recorded by UAA, not the Cloud Controller audit log, so they don’t appear in activity.

​
Prerequisites

  • A Cloud Foundry foundation and its Cloud Controller API endpoint, for example https://api.cf.us10-001.hana.ondemand.com on SAP BTP or https://api.sys.example.com on open-source Cloud Foundry or Tanzu.
  • A credential Oleria can use: a UAA client, or a technical user (see below).
  • Admin access on the Oleria platform to add a new integration.
SAP BTP endpoints (*.hana.ondemand.com) work as is. For open-source Cloud Foundry or Tanzu on your own domain, Oleria must reach the Cloud Controller API, login and UAA hosts over HTTPS (for example api.sys.example.com, login.sys.example.com and uaa.sys.example.com; open https://<api-endpoint>/ to see the login and uaa links your foundation advertises). Contact support@oleria.com to have these hostnames allowed before you connect.

​
Prepare a credential in Cloud Foundry

1

Choose a UAA client or a technical user

  • UAA client (client credentials). Recommended for open-source Cloud Foundry and Tanzu. Ask your platform operator to create a UAA client for Oleria.
  • Technical user (password). The usual choice on SAP BTP, where you can’t create UAA clients. Use a dedicated user from SAP ID service or your identity provider.
A technical user must not have multi-factor authentication enforced, because Oleria signs in without an interactive prompt.
2

Grant access to each org

Give the client or user Org Manager and Org Auditor in every org you want Oleria to govern. Org Manager lets Oleria see every space, user, and role in the org, and Org Auditor makes org-level audit events visible. Org Manager also lets Oleria grant, revoke, and remove org and space roles. Revoking service keys and the UAA user and group actions need more; see Remediation actions. Oleria makes changes only when you run one.On open-source Cloud Foundry or Tanzu you can instead give a UAA client the cloud_controller.global_auditor or cloud_controller.admin_read_only authority to read the whole foundation. Global auditor is the lower-privilege option, because it can’t read secrets or environment variables. Neither lets Oleria run remediation actions.
3

Optional: grant UAA scopes for richer data

On open-source Cloud Foundry and Tanzu, add these UAA scopes to the client:
  • scim.read: user status, name, last sign-in and UAA groups;
  • clients.read: UAA clients and their secrets as credentials;
  • idps.read: identity-provider details.
These scopes are not available on SAP BTP; Oleria works without them. The remediation actions section lists the scopes each action needs.

​
Connect Cloud Foundry to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations, then select the Cloud Foundry tile.
2

Complete the connection form

Select Continue and fill in the connection form:
3

Save the integration

Select Authenticate to validate the credential and save the integration. Oleria refuses a credential that can’t see any org, because nothing would be imported.
To rotate a secret later, edit the integration and enter the new secret. Leave the secret blank to keep the stored one.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. Users, roles, resources, machine identities and audit activity appear after the first sync completes.

​
Remediation actions

Oleria can also act in Cloud Foundry:
  • Grant or revoke an org or space role.
  • Remove a user’s access to an org or space. Oleria removes the user’s space roles first and the org membership last, which is the order Cloud Foundry requires. On a space, this removes the user’s space roles only: an Org Manager keeps access to every space in the org, so remove the Org Manager role on the org instead. Apps and service instances get their access from the space, so revoke the space role.
  • Revoke a service key. This can’t be undone, because a new key has new credentials.
  • Add or remove a user in a UAA group.
  • Disable or enable a user, or revoke all of a user’s sessions. Disabling blocks new sign-ins only; sessions already open keep working, so also revoke the user’s sessions. Revoking sessions ends the user’s refresh tokens, but an access token already issued stays valid in Cloud Controller until it expires.
  • Create a user (a UAA-local user with a password, not a user from your identity provider; it’s created inactive unless you choose to activate it, and a password Oleria generates isn’t shown or stored, so the user sets a new one through UAA’s password reset; if the username already exists, nothing changes, and the action fails if you also chose groups) or a UAA group, or delete a user. Deleting a user removes it from Cloud Controller, with all its org and space roles, and from UAA.
The UAA group and user actions work on open-source Cloud Foundry and Tanzu. SAP BTP doesn’t grant the UAA scopes they need, so there your identity provider manages users, and Oleria shows these actions as unavailable. Every action can be reverted from Oleria except revoking a service key, revoking sessions and deleting a user. These actions need the cloud_controller.write scope, which technical users have by default, plus the matching Cloud Foundry role:
  • Org Manager, or Space Manager for space roles, to grant, revoke or remove access;
  • Space Developer in the space to revoke its service keys.
The UAA actions need these scopes:
  • scim.read and scim.write to add or remove users in UAA groups, and to disable or enable users;
  • scim.write to create users and groups (adding a new user to groups also needs scim.read);
  • scim.read and tokens.revoke to revoke a user’s sessions;
  • scim.read, scim.write and cloud_controller.admin to delete a user.
uaa.admin covers all of these UAA scopes. Oleria won’t revoke roles from, remove, disable, sign out or delete the client or technical user it connects with. Oleria only makes changes in Cloud Foundry when you run a remediation action.

​
Known limitations

  • Cloud Foundry keeps audit events only for the retention your operator configures (31 days by default), so the first sync can’t import older activity.
  • Oleria imports service keys but not app bindings, the credentials Cloud Foundry injects into apps.
  • UAA clients are discovered but can’t be disabled from Oleria. Only service keys can be revoked.
  • On SAP BTP, Oleria can’t read UAA, so every user shows as enabled and Oleria can’t show last sign-in or last password change, or detect dormant users.
  • Cloud Foundry doesn’t expose multi-factor authentication status. Your identity provider’s integration provides it.

​
Contact us

For questions about this integration, contact us at support@oleria.com.