Provisioning, Connectivity, and Security Configuration for HANA Cloud Instances

Explanation

Once a team decides to use HANA Cloud, the next set of decisions concerns provisioning, connectivity, and security, and getting these wrong is one of the most common sources of production incidents in BTP integration projects. Provisioning starts in the BTP cockpit or via the Cloud Foundry command-line interface, where you create a HANA Cloud instance under an entitlement assigned to the subaccount. Key decisions at this stage include the service plan (which governs compute units, memory, and storage allocation), the region (which affects data residency and latency to consuming applications), and whether the instance will support additional capabilities such as script server for AFL/PAL algorithms or data lake integration for cold storage. Connectivity differs meaningfully between Cloud Foundry and Kyma. In Cloud Foundry, an application binds to the HANA Cloud service instance, and the platform automatically injects connection credentials (host, port, user, password, certificate information) into the application's environment via VCAP_SERVICES. CAP applications read these bindings automatically through the CDS/HDI tooling, meaning developers rarely handle raw credentials directly. In Kyma, which is Kubernetes-based, there is no automatic VCAP-style injection; instead, a ServiceInstance and ServiceBinding (via the SAP BTP service operator) create a Kubernetes Secret containing the connection details, which the application's deployment manifest mounts as environment variables or files. For external tools (local development, ETL jobs outside BTP, or third-party analytics tools), you generate a service key, which produces a static set of credentials; because service keys do not rotate automatically like bound credentials, they require lifecycle management and should be treated as sensitive secrets with periodic rotation. Security configuration has several layers. At the instance level, HANA Cloud supports IP allowlisting so that only specified network ranges (for example, a Cloud Connector's egress IP or a corporate VPN range) can reach the database endpoint; leaving this open to all IPs is a common but risky default that should be tightened before go-live. At the database level, the initial administrator account should not be used for day-to-day application connectivity; instead, create dedicated technical users with least-privilege roles scoped to specific HDI container schemas. HDI container deployment automatically creates a container-specific technical user with rights limited to that schema, which is the preferred pattern for CAP-based applications rather than granting broad SELECT/INSERT rights across schemas. Authentication can also be integrated with SAP Cloud Identity Services or platform identity providers for named user access to tools like the SAP HANA Cloud Central cockpit or database explorer, separating administrative human access from application technical users. Auditing should be enabled for sensitive schemas, capturing data access and structural changes, and audit logs should be routed to a retention target that satisfies compliance requirements, since default retention windows are often too short for audit purposes. On the runtime side, once an application is connected, monitoring connectivity health matters: connection pool exhaustion, expired service keys, and IP allowlist misconfigurations are the most frequent causes of "application cannot reach database" incidents in production. A support engineer troubleshooting such an issue should first verify whether the service binding or key is still valid, then check IP allowlist entries against the actual outbound IP of the consuming application (which may change if it moves to a different Cloud Foundry organization/space or if a Cloud Connector's IP changes), and finally check HANA Cloud Central for instance health status before assuming an application-side bug. Finally, differences from on-premise thinking are important here: there is no direct OS-level access to patch or restart the database manually, backups and patching are managed by SAP on a defined schedule, and customers interact with the instance through cockpit tools, APIs, and SQL rather than traditional DBA console access.

Code example

# Example: creating a service key for external connectivity (Cloud Foundry CLI)cf create-service-key my-hana-cloud-instance my-hana-key cf service-key my-hana-cloud-instance my-hana-key# Output includes host, port, user, and certificate info used to configure# a JDBC connection string, e.g.:# jdbc:sap://<host>:443/?encrypt=true&validateCertificate=true # Example: Kyma ServiceBinding referencing a HANA Cloud ServiceInstanceapiVersion: services.cloud.sap.com/v1kind: ServiceBindingmetadata:  name: hana-cloud-bindingspec:  serviceInstanceName: hana-cloud-instance  secretName: hana-cloud-secret

Real project scenario

An integration team deploys a CAP-based approval microservice to Cloud Foundry bound to a HANA Cloud instance. After a network security review, IP allowlisting is enabled on the instance, restricting access only to the Cloud Connector's known egress IPs and the Cloud Foundry runtime's outbound range. A few weeks later, a scheduled batch job running from an on-premise ETL server starts failing intermittently; investigation reveals the on-premise proxy's outbound IP had changed during a data-center migration, so it was no longer in the allowlist, and the fix was updating the allowlist entry and rotating the associated service key as a precaution.

Common mistakes

• Leaving the HANA Cloud instance open to all IP addresses instead of applying allowlisting before production go-live. • Using the administrative DBADMIN-type account for routine application connectivity instead of scoped technical users. • Forgetting that service keys are static credentials requiring manual rotation, unlike auto-rotated service bindings. • Not accounting for Kyma's different connectivity model (Secrets via service operator) when a team is used to Cloud Foundry's VCAP_SERVICES pattern. • Granting broad cross-schema privileges instead of using HDI container-scoped technical users for least privilege.

Best practices

• Apply IP allowlisting on every HANA Cloud instance before production use. • Use HDI container-scoped technical users rather than administrative accounts for application connectivity. • Rotate service keys periodically and treat them as sensitive secrets in a vault, not plain text config. • Monitor instance health via HANA Cloud Central and correlate connectivity incidents with allowlist and credential validity before assuming application bugs. • Document connectivity architecture separately for Cloud Foundry and Kyma consumers since the mechanisms differ.

Interview angle

Expect questions distinguishing how Cloud Foundry service bindings differ from Kyma ServiceBindings/Secrets, and why service keys need separate lifecycle management. A strong candidate can explain least-privilege technical user design via HDI containers and describe a realistic troubleshooting flow for connectivity failures involving IP allowlisting.