If you've set up a staged development environment using different subaccounts or spaces, such as for development, testing, and production, grant the Cloud Development Team access to development subaccounts and environments. Only grant the Platform Engineering Team access to the testing and production subaccounts or environments.
All developers and stakeholders for a particular development project or application should get access to the development subaccount or environment, if the project or application has been properly enrolled. We recommend that you assign all developers authorizations to develop, assign roles, and test the application's functionalities.
In cases where even the Platform Engineering Team isn't allowed to see or access the data, automate tasks that require developer access or integrate them into a deployment pipeline using a technical user with the developer authorizations. Firefighter situations where temporary use of the role is needed for manual actions by an actual administrative user can be handled by temporary assignment of the developer access. You can also use a special user account with access whose credentials are only given out when needed and changed immediately after use. Remember to log the use of this role in an audit trail or another tracking tool.
As every small change that's made in a single application (for example, changing a destination) can affect all other applications. Only grant the Platform Engineering Team access to the test and prod subaccounts or environments. Have this team manage them centrally. If necessary, assign developers read access. For all changes required in subaccounts or spaces, the Cloud Development Team should reach out to the Platform Engineering Team.
Division of Access to Different Stages of the Development Pipeline
To avoid overwhelming the Platform Engineering Team with inquiries, consider automating tasks and providing a build infrastructure for continuous deployment.
Platform users depend on role collections for access at the global account and directory level. By default, user management isn't enabled for directories. To manage platform users at this level, use SAP BTP cockpit or the btp cli.
For more information, see:
See Add Members to Your Subaccount
We recommend that you assign all developers the Space Developer role, so they can develop, assign roles, and test the application's functionalities.
The
Space Developerrole has broad rights within Cloud Foundry and, in particular, has access to the credentials used in various services and app bindings as well as other sensitive data. Users with this role can access the data in the environment, either directly through administration tools or indirectly through an application or other client.
In production environments, only give this role to members of the Platform Engineering Team that are authorized to access data in the environment.
For more information, see About User Management in the Cloud Foundry Environment.
Platform users in the ABAP environment depend on Cloud Foundry. Administrators need the Org Manager and Space Manager roles. Developers need the Space Developer role. The same recommendations apply as in the Cloud Foundry environment to members of the Cloud Development and Platform Engineering teams.
In addition, platform users need the relevant business roles of the ABAP system: SAP_BR_ADMINISTRATOR and SAP_BR_DEVELOPER.
For more information, see Creation of Additional Administrator Users and Creation of Developer Users.
You can assign roles to a group of users only if you use a custom identity provider. Assigning roles in Kyma is based on the Kubernetes role-based access control (RBAC). Once you become the admin, your user name is read from the SAP BTP (RBAC) concept and is passed to the Kyma provisioner to be bound to the cluster-admin role in Kyma.
Because the development of a role concept is very specific for each organization, it’s recommended that you start with a very simple role concept: As a starting point, just separate the developers and operators of a cluster. Later, you can refine the role concept as needed.
For more information, see Role-Based Access Control (RBAC) in Kyma and Assign Roles in the Kyma Environment.
Assign the predefined platform roles for platform users. You can also configure custom roles.
For more information, see:
Related Information