From 08c28267de3080efac6597c5fa65ec0ce47f0585 Mon Sep 17 00:00:00 2001 From: I501080 Date: Sun, 28 Jan 2024 11:52:39 +0200 Subject: [PATCH] keren --- README.md | 246 +++++++++++++++++++++++++++--------------------------- 1 file changed, 122 insertions(+), 124 deletions(-) diff --git a/README.md b/README.md index 4eae9924..a6691a1b 100644 --- a/README.md +++ b/README.md @@ -127,9 +127,129 @@ It is implemented using a [CRDs-based](https://kubernetes.io/docs/concepts/exten --set manager.secret.tokenurl= ``` **Note:**
In order to rotate the credentials between the BTP service operator and Service Manager, you have to create a new binding for the service-operator-access service instance, and then to execute the setup script again, with the new set of credentials. Afterwards you can delete the old binding. - -[Back to top](#sap-business-technology-platform-sap-btp-service-operator-for-kubernetes). + +## Working with Multiple Subaccounts + +By default, a Kubernetes cluster is related to one subaccount (see step 4 of the [Setup](#setup) section.) + +* Obtain the SAP BTP service operator's [access credentials](#setup). + +* Store these credentials securely in a secret. + +The subaccount is determined by the credentials stored in the secret. +You have several options at your disposal to define working with multiple subaccounts in a cluster by configuring dedicated secrets + + +### Default Subaccount For Namespace + +To associate namespace to a specific subaccount you maintain the access credentials to the subaccount in a secret which is dedicated to a specific namespace. +Define a secret named: `-sap-btp-service-operator` in the Centrally Managed Namespace. + +**Note:** +The system's centrally-managed namespace is set by the value in `.Values.manager.management_namespace`. You can provide this value during installation (refer to step 4 in the [Setup](#setup) section). +If you don't specify this value, the system will use the installation namespace as the default. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: -sap-btp-service-operator + namespace: +type: Opaque +data: + clientid: "" + clientsecret: "" + sm_url: "" + tokenurl: "" + tokenurlsuffix: "/oauth/token" +``` +If you are using TLS binding, create additional secret named `-sap-btp-service-operator-tls` which contains the TLS certificate and key. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: -sap-btp-service-operator-tls + namespace: +type: kubernetes.io/tls +data: + tls.crt: #base64 encoded + tls.key: #base64 encoded +``` + + +### Explicit Subaccount For Resource + +To associate `ServiceInstance` to a specific subaccount you maintain the access credentials to the subaccount in a secret which is located in the Centrally Managed Namespace. + +#### Define a new secret +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mybtpsecret + namespace: +type: Opaque +data: + clientid: "" + clientsecret: "" + sm_url: "" + tokenurl: "" + tokenurlsuffix: "/oauth/token" +``` + +#### Configure the secret name in the `ServiceInstance` resource within the property `btpAccessCredentialsSecret`: +```yaml +apiVersion: services.cloud.sap.com/v1 +kind: ServiceInstance +metadata: + name: sample-instance-1 +spec: + serviceOfferingName: service-manager + servicePlanName: subaccount-audit + btpAccessCredentialsSecret: mybtpsecret +``` + +##### Secrets priority +The following list shows the priority of the secrets that are used to authenticate the SAP BTP service operator: +1. Explicit secret defined in the `ServiceInstance` resource +2. Default namespace secret +3. Default cluster secret + +[Back to top](#sap-business-technology-platform-sap-btp-service-operator-for-kubernetes) + +## Developer Mode Secret +Define a secret named `sap-btp-service-operator` in the namespace. +`ServiceInstance` and `ServiceBinding` applied in the namespace belong to the subaccount from which the credentials were issued. + +#### Namespace Secret Structure +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: sap-btp-service-operator + namespace: +type: Opaque +data: + clientid: "" + clientsecret: "" + sm_url: "" + tokenurl: "" + tokenurlsuffix: "/oauth/token" +``` +with TLS configurations: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: sap-btp-service-operator-tls + namespace: +type: kubernetes.io/tls +data: + tls.crt: #base64 encoded + tls.key: #base64 encoded +``` ## Versions Review the supported Kubernetes API versions for the following SAP BTP Service Operator versions. @@ -428,128 +548,6 @@ You can also choose the `services.cloud.sap.com/forceRotate` annotation (value d [Back to top](#sap-business-technology-platform-sap-btp-service-operator-for-kubernetes) -## Working with Multiple Subaccounts - -By default, a Kubernetes cluster is related to one subaccount (see step 4 of the [Setup](#setup) section.) - -* Obtain the SAP BTP service operator's [access credentials](#setup). - -* Store these credentials securely in a secret. - -You have several options at your disposal to define working with multiple subaccounts in a cluster by configuring dedicated secrets - - -### Default Secret For Namespace - -To associate namespace to a specific subaccount you maintain the access credentials to the subaccount in a secret which is dedicated to a specific namespace. -Define a secret named: `-sap-btp-service-operator` in the Centrally Managed Namespace. - -**Note:** -The system's centrally-managed namespace is set by the value in `.Values.manager.management_namespace`. You can provide this value during installation (refer to step 4 in the [Setup](#setup) section). -If you don't specify this value, the system will use the installation namespace as the default. - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: -sap-btp-service-operator - namespace: -type: Opaque -data: - clientid: "" - clientsecret: "" - sm_url: "" - tokenurl: "" - tokenurlsuffix: "/oauth/token" -``` -If you are using TLS binding, create additional secret named `-sap-btp-service-operator-tls` which contains the TLS certificate and key. - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: -sap-btp-service-operator-tls - namespace: -type: kubernetes.io/tls -data: - tls.crt: #base64 encoded - tls.key: #base64 encoded -``` - - -### Explicit Subaccount For Resource - -To associate `ServiceInstance` to a specific subaccount you maintain the access credentials to the subaccount in a secret which is located in the Centrally Managed Namespace. - -#### Define a new secret -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: mybtpsecret - namespace: -type: Opaque -data: - clientid: "" - clientsecret: "" - sm_url: "" - tokenurl: "" - tokenurlsuffix: "/oauth/token" -``` - -#### Configure the secret name in the `ServiceInstance` resource within the property `btpAccessCredentialsSecret`: -```yaml -apiVersion: services.cloud.sap.com/v1 -kind: ServiceInstance -metadata: - name: sample-instance-1 -spec: - serviceOfferingName: service-manager - servicePlanName: subaccount-audit - btpAccessCredentialsSecret: mybtpsecret -``` - -##### Secrets priority -The following list shows the priority of the secrets that are used to authenticate the SAP BTP service operator: -1. Explicit secret defined in the `ServiceInstance` resource -2. Default namespace secret -3. Default cluster secret - -[Back to top](#sap-business-technology-platform-sap-btp-service-operator-for-kubernetes) - -### Developer Mode Secret -To allow a user to work with.... -Define a secret named `sap-btp-service-operator` in the namespace. -`ServiceInstance` and `ServiceBinding` applied in the namespace belong to the subaccount from which the credentials were issued. - -#### Namespace Secret Structure -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: sap-btp-service-operator - namespace: -type: Opaque -data: - clientid: "" - clientsecret: "" - sm_url: "" - tokenurl: "" - tokenurlsuffix: "/oauth/token" -``` -with TLS configurations: -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: sap-btp-service-operator-tls - namespace: -type: kubernetes.io/tls -data: - tls.crt: #base64 encoded - tls.key: #base64 encoded -``` - ## Troubleshooting and Support #### Cannot Create a Service Binding for Service Instance in `Delete Failed` State