diff --git a/doc/source/security/kubernetes/add-a-trusted-ca.rst b/doc/source/security/kubernetes/add-a-trusted-ca.rst index 724e98503..949ad957f 100644 --- a/doc/source/security/kubernetes/add-a-trusted-ca.rst +++ b/doc/source/security/kubernetes/add-a-trusted-ca.rst @@ -39,7 +39,7 @@ For example: .. code-block:: none - apiserver_cert_sans: + ssl_ca_cert: /path/to/ssl_ca_cert_file The *ssl\_ca\_cert* value is the absolute path of the file containing the |CA| certificate\(s\) to trust. The certificate\(s\) must be in |PEM| format @@ -62,14 +62,14 @@ From the command line, run the :command:`certificate-install` command. .. code-block:: none - ~(keystone_admin)$ system certificate-install -m ssl_ca + ~(keystone_admin)]$ system certificate-install -m ssl_ca For example: .. code-block:: none - ~(keystone_admin)$ system certificate-install -m ssl_ca external-registry-ca-crt.pem + ~(keystone_admin)]$ system certificate-install -m ssl_ca external-registry-ca-crt.pem WARNING: For security reasons, the original certificate, containing the private key, will be removed, once the private key is processed. @@ -100,7 +100,7 @@ running the following command: .. code-block:: none - ~(keystone_admin)$ system certificate-list + ~(keystone_admin)]$ system certificate-list where, all entries with certtype = ssl\_ca are trusted |CA| certificates. @@ -109,7 +109,7 @@ running the following command: .. code-block:: none - ~(keystone_admin)$ system certificate-uninstall -m ssl_ca + ~(keystone_admin)]$ system certificate-uninstall -m ssl_ca where, is the UUID of the ssl\_ca certtype to be removed. diff --git a/doc/source/security/kubernetes/authentication-of-software-delivery.rst b/doc/source/security/kubernetes/authentication-of-software-delivery.rst index eb5edb754..13ca7f124 100644 --- a/doc/source/security/kubernetes/authentication-of-software-delivery.rst +++ b/doc/source/security/kubernetes/authentication-of-software-delivery.rst @@ -23,3 +23,6 @@ This is done for: Both software patches and loads are cryptographically signed as part of |org| builds and are authenticated before they are loaded on a system via |prod| REST APIs, CLIs or GUI. + +.. xbooklink For more information on patches, see |updates-doc|: :ref:`Software Updates + `. \ No newline at end of file diff --git a/doc/source/security/kubernetes/configure-horizon-user-lockout-on-failed-logins.rst b/doc/source/security/kubernetes/configure-horizon-user-lockout-on-failed-logins.rst index 41c7e8dff..e7c9e6838 100644 --- a/doc/source/security/kubernetes/configure-horizon-user-lockout-on-failed-logins.rst +++ b/doc/source/security/kubernetes/configure-horizon-user-lockout-on-failed-logins.rst @@ -32,7 +32,7 @@ You can change the duration of the lockout using the following CLI command: .. code-block:: none - ~(keystone_admin)$ system service-parameter-modify horizon auth \ + ~(keystone_admin)]$ system service-parameter-modify horizon auth \ lockout_seconds= where is the time in seconds. @@ -42,7 +42,7 @@ using the following CLI command: .. code-block:: none - ~(keystone_admin)$ system service-parameter-modify horizon auth \ + ~(keystone_admin)]$ system service-parameter-modify horizon auth \ lockout_retries= where is the number of allowed retries. @@ -51,7 +51,7 @@ For the changes to take effect, you must apply them: .. code-block:: none - ~(keystone_admin)$ system service-parameter-apply horizon + ~(keystone_admin)]$ system service-parameter-apply horizon Allow about 30 seconds after applying the changes for the Web service to restart. diff --git a/doc/source/security/kubernetes/configure-http-and-https-ports-for-horizon-using-the-cli.rst b/doc/source/security/kubernetes/configure-http-and-https-ports-for-horizon-using-the-cli.rst index 1a65fd71c..3b8fc4f0a 100644 --- a/doc/source/security/kubernetes/configure-http-and-https-ports-for-horizon-using-the-cli.rst +++ b/doc/source/security/kubernetes/configure-http-and-https-ports-for-horizon-using-the-cli.rst @@ -24,7 +24,7 @@ list the configured **HTTP**, and **HTTPS** ports. .. code-block:: none - ~(keystone_admin)$ system service-parameter-list --service http + ~(keystone_admin)]$ system service-parameter-list --service http +---------+----------+---------+------------+-------+------------+--------+ | uuid | service | section | name | value |personality |Resource| +---------+----------+---------+------------+-------+------------+--------+ @@ -39,16 +39,16 @@ list the configured **HTTP**, and **HTTPS** ports. .. code-block:: none - ~(keystone_admin)$ system service-parameter-modify http config http_port=8090 + ~(keystone_admin)]$ system service-parameter-modify http config http_port=8090 - ~(keystone_admin)$ system service-parameter-modify http config https_port=9443 + ~(keystone_admin)]$ system service-parameter-modify http config https_port=9443 #. Apply the service parameter change. .. code-block:: none - ~(keystone_admin)$ system service-parameter-apply http + ~(keystone_admin)]$ system service-parameter-apply http Applying http service parameters .. note:: diff --git a/doc/source/security/kubernetes/configure-kubectl-with-a-context-for-the-user.rst b/doc/source/security/kubernetes/configure-kubectl-with-a-context-for-the-user.rst index 7011b136f..834d27b1f 100644 --- a/doc/source/security/kubernetes/configure-kubectl-with-a-context-for-the-user.rst +++ b/doc/source/security/kubernetes/configure-kubectl-with-a-context-for-the-user.rst @@ -21,14 +21,14 @@ do so from a remote workstation. .. code-block:: none - ~(keystone_admin)$ kubectl config set-cluster mywrcpcluster --server=https://:6443 + ~(keystone_admin)]$ kubectl config set-cluster mywrcpcluster --server=https://:6443 #. Set up a context for **testuser** in this cluster in kubectl. .. code-block:: none - ~(keystone_admin)$ kubectl config set-context testuser@mywrcpcluster --cluster=mywrcpcluster --user=testuser + ~(keystone_admin)]$ kubectl config set-context testuser@mywrcpcluster --cluster=mywrcpcluster --user=testuser diff --git a/doc/source/security/kubernetes/configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system.rst b/doc/source/security/kubernetes/configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system.rst index 8f8872974..2d218349c 100644 --- a/doc/source/security/kubernetes/configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system.rst +++ b/doc/source/security/kubernetes/configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system.rst @@ -30,7 +30,7 @@ you can do so at any time using service parameters. .. code-block:: none - ~(keystone_admin)$ system service-parameter-add kubernetes kube_apiserver oidc_client_id=stx-oidc-client-app + ~(keystone_admin)]$ system service-parameter-add kubernetes kube_apiserver oidc_client_id=stx-oidc-client-app - oidc\_client\_id= @@ -67,7 +67,7 @@ you can do so at any time using service parameters. .. code-block:: none - ~(keystone_admin)$ system service-parameter-apply kubernetes + ~(keystone_admin)]$ system service-parameter-apply kubernetes For more information on |OIDC| Authentication for subclouds, see :ref:`Centralized OIDC Authentication Setup for Distributed Cloud diff --git a/doc/source/security/kubernetes/configure-local-cli-access.rst b/doc/source/security/kubernetes/configure-local-cli-access.rst index 0f7716c7f..adc17e4cb 100644 --- a/doc/source/security/kubernetes/configure-local-cli-access.rst +++ b/doc/source/security/kubernetes/configure-local-cli-access.rst @@ -55,6 +55,18 @@ required system maintenance, administration and troubleshooting tasks. % echo "export KUBECONFIG=~/.kube/config" >> ~/.profile % exit + .. note:: + The command + + .. code-block:: none + + echo "export KUBECONFIG=~/.kube/config" >> ~/.profile + + shown above is specific to CentOS. Substitute the correct syntax for your operating system. The following alternative is for Ubuntu: + + .. code-block:: none + + echo "export KUBECONFIG=~/.kube/config" >> ~/.bashrc #. Confirm that the environment variable is set correctly and that :command:`kubectl` commands are functioning properly. @@ -80,7 +92,7 @@ For example: .. code-block:: none - ~(keystone_admin)$ system host-list + ~(keystone_admin)]$ system host-list +----+--------------+-------------+----------------+-------------+--------------+ | id | hostname | personality | administrative | operational | availability | +----+--------------+-------------+----------------+-------------+--------------+ @@ -104,7 +116,7 @@ For example: .. code-block:: none - ~(keystone_admin)$ fm alarm-list + ~(keystone_admin)]$ fm alarm-list +-------+---------------+---------------------+----------+---------------+ | Alarm | Reason Text | Entity ID | Severity | Time Stamp | @@ -125,10 +137,10 @@ For example: .. code-block:: none - ~(keystone_admin)$ kubectl get nodes + ~(keystone_admin)]$ kubectl get nodes NAME STATUS ROLES AGE VERSION controller-0 Ready master 5d19h v1.13.5 - ~(keystone_admin)$ kubectl get pods + ~(keystone_admin)]$ kubectl get pods NAME READY STATUS RESTARTS AGE dashboard-kubernetes-dashboard-7749d97f95-bzp5w 1/1 Running 0 3d18h diff --git a/doc/source/security/kubernetes/configure-oidc-auth-applications.rst b/doc/source/security/kubernetes/configure-oidc-auth-applications.rst index 7521aa6f4..66a3fdc7f 100644 --- a/doc/source/security/kubernetes/configure-oidc-auth-applications.rst +++ b/doc/source/security/kubernetes/configure-oidc-auth-applications.rst @@ -82,22 +82,22 @@ and uploaded by default. .. code-block:: none - ~(keystone_admin)$ kubectl create secret tls local-dex.tls --cert=ssl/dex-cert.pem --key=ssl/dex-key.pem -n kube-system + ~(keystone_admin)]$ kubectl create secret tls local-dex.tls --cert=ssl/dex-cert.pem --key=ssl/dex-key.pem -n kube-system - ~(keystone_admin)$ kubectl create secret generic dex-client-secret --from-file=/home/sysadmin/ssl/dex-ca.pem -n kube-system + ~(keystone_admin)]$ kubectl create secret generic dex-client-secret --from-file=/home/sysadmin/ssl/dex-ca.pem -n kube-system Create the secret **wadcert** with the |CA|'s certificate that signed the Active Directory's certificate using the following command: .. code-block:: none - ~(keystone_admin)$ kubectl create secret generic wadcert --from-file=ssl/AD_CA.cer -n kube-system + ~(keystone_admin)]$ kubectl create secret generic wadcert --from-file=ssl/AD_CA.cer -n kube-system #. Specify user overrides for **oidc-auth-apps** application, by using the following command: .. code-block:: none - ~(keystone_admin)$ system helm-override-update oidc-auth-apps dex kube-system --values /home/sysadmin/dex-overrides.yaml + ~(keystone_admin)]$ system helm-override-update oidc-auth-apps dex kube-system --values /home/sysadmin/dex-overrides.yaml The dex-overrides.yaml file contains the desired dex helm chart overrides \(that is, the LDAP connector configuration for the Active Directory @@ -119,9 +119,44 @@ and uploaded by default. Directory service login information \(that is, bindDN, and bindPW\), and example :command:`userSearch`, and :command:`groupSearch` clauses. + \(Optional\) There is a default secret in the dex configuration for + **staticClients**. You can change this using helm overrides. For example, + to change the secret, first run the following command to see the default + settings. In this example, 10.10.10.2 is the |prod-long| |OAM| floating IP + address. + + .. code-block:: none + + ~(keystone_admin)]$ system helm-override-show oidc-auth-apps dex kube-system + + config: + staticClients: + - id: stx-oidc-client-app + name: STX OIDC Client app + redirectURIs: ['https://10.10.10.2:30555/callback'] + secret: St8rlingX + + Change the secret from the output and copy the entire configuration section + shown above in to your dex overrides file shown in the example below. + + .. note:: + Do NOT forget to include the id, name, and redirectURIs parameters. + + .. note:: + There is an internal **client\_secret** that is used between the + oidc-client container and the dex container. It is recommended that you + configure a unique, more secure **client\_secret** by specifying the + value in the dex overrides file, as shown in the example below. + .. code-block:: none config: + staticClients: + - id: stx-oidc-client-app + name: STX OIDC Client app + redirectURIs: ['/callback'] + secret: BetterSecret + client_secret: BetterSecret expiry: idTokens: "10h" connectors: @@ -134,7 +169,7 @@ and uploaded by default. insecureNoSSL: false insecureSkipVerify: false bindDN: cn=Administrator,cn=Users,dc=cumulus,dc=wrs,dc=com - bindPW: Li69nux* + bindPW: [] usernamePrompt: Username userSearch: baseDN: ou=Users,ou=Titanium,dc=cumulus,dc=wrs,dc=com @@ -155,7 +190,7 @@ and uploaded by default. secretName: wadcert extraVolumeMounts: - name: certdir - mountPath: /etc/ssl/certs/adcer + mountPath: /etc/ssl/certs/adcert If more than one Windows Active Directory service is required for authenticating the different users of the |prod|, multiple '**ldap**' @@ -170,11 +205,35 @@ and uploaded by default. Whenever you use multiple '**ldap**' type connectors, ensure you use unique '**name:**' and '**id:**' parameters for each connector. +#. An override in the secrets in the dex helm chart must be accompanied by an + override in the oidc-client helm chart. + + The following override is sufficient for changing the secret in the + /home/sysadmin/oidc-client-overrides.yaml file. + + .. code-block:: none + + config: + client_secret: BetterSecret + + Apply the oidc-client overrides using the following command: + + .. code-block:: none + + ~(keystone_admin)]$ system helm-override-update oidc-auth-apps oidc-client kube-system --values /home/sysadmin/oidc-client-overrides.yaml + + .. note:: + + If you need to manually override the secrets, the client\_secret in the + oidc-client overrides must match the staticClients secret and + client\_secret in the dex overrides, otherwise the oidc-auth |CLI| + client will not function. + #. Use the :command:`system application-apply` command to apply the configuration: .. code-block:: none - ~(keystone_admin)$ system application-apply oidc-auth-apps + ~(keystone_admin)]$ system application-apply oidc-auth-apps diff --git a/doc/source/security/kubernetes/configure-remote-cli-access.rst b/doc/source/security/kubernetes/configure-remote-cli-access.rst index 8ad4a3d0d..7e2da90e4 100644 --- a/doc/source/security/kubernetes/configure-remote-cli-access.rst +++ b/doc/source/security/kubernetes/configure-remote-cli-access.rst @@ -36,6 +36,9 @@ either of the above two methods. :ref:`Configure Container-backed Remote CLIs and Clients ` + :ref:`Using Container-backed Remote CLIs and Clients + ` + :ref:`Install Kubectl and Helm Clients Directly on a Host ` diff --git a/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst b/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst index 152226e09..2c6fa1ef2 100644 --- a/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst +++ b/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst @@ -26,7 +26,7 @@ remotely. .. note:: If you are using container-backed helm CLIs and clients \(method 1\), - ensure you change directories to <$HOME>/remote\_wd + ensure you change directories to <$HOME>/remote\_cli\_wd .. rubric:: |proc| @@ -37,7 +37,7 @@ remotely. .. code-block:: none - ~(keystone_admin)$ NAMESPACE=default + ~(keystone_admin)]$ NAMESPACE=default #. Set up accounts, roles and bindings. @@ -50,7 +50,7 @@ remotely. .. code-block:: none - % cat < default-tiller-sa.yaml + ~(keystone_admin)]$ cat < default-tiller-sa.yaml apiVersion: v1 kind: ServiceAccount metadata: @@ -81,16 +81,16 @@ remotely. name: tiller namespace: default EOF - % kubectl apply -f default-tiller-sa.yaml + ~(keystone_admin)]$ kubectl apply -f default-tiller-sa.yaml #. Execute the following commands as an admin-level user. .. code-block:: none - ~(keystone_admin)$ kubectl create clusterrole tiller --verb get + ~(keystone_admin)]$ kubectl create clusterrole tiller --verb get --resource namespaces - ~(keystone_admin)$ kubectl create clusterrolebinding tiller + ~(keystone_admin)]$ kubectl create clusterrolebinding tiller --clusterrole tiller --serviceaccount ${NAMESPACE}:tiller @@ -98,13 +98,13 @@ remotely. .. code-block:: none - ~(keystone_admin)$ helm init --service-account=tiller + ~(keystone_admin)]$ helm init --service-account=tiller --tiller-namespace=$NAMESPACE --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | sed 's@ replicas: 1@ replicas: 1\n \ selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' > helm-init.yaml - ~(keystone_admin)$ kubectl apply -f helm-init.yaml - ~(keystone_admin)$ helm init –client-only + ~(keystone_admin)]$ kubectl apply -f helm-init.yaml + ~(keystone_admin)]$ helm init --client-only --home "./.helm" .. note:: Ensure that each of the patterns between single quotes in the above @@ -144,7 +144,7 @@ example: .. note:: If you are using container-backed helm CLI and Client \(method 1\), then - you change directory to <$HOME>/remote\_wd and include the following + you change directory to <$HOME>/remote\_cli\_wd and include the following option on all helm commands: .. code-block:: none @@ -160,6 +160,9 @@ example: :ref:`Configure Container-backed Remote CLIs and Clients ` + :ref:`Using Container-backed Remote CLIs and Clients + ` + :ref:`Install Kubectl and Helm Clients Directly on a Host ` diff --git a/doc/source/security/kubernetes/configure-vault.rst b/doc/source/security/kubernetes/configure-vault.rst index 348a37a2e..a67d83cc7 100644 --- a/doc/source/security/kubernetes/configure-vault.rst +++ b/doc/source/security/kubernetes/configure-vault.rst @@ -133,7 +133,7 @@ The following steps use Vault's REST API and is run from controller-0. .. code-block:: none - $ curl --cacert /home/sysadmin/vault_ca.pem --header "X-Vault-Token:$ROOT_TOKEN" -H "Content-Type: application/json" -X POST -d '{"username":"pvtest","password":"Li69nux*"}' https://sva-vault.vault.svc.cluster.local:8200/v1/secret/basic-secret/helloworld + $ curl --cacert /home/sysadmin/vault_ca.pem --header "X-Vault-Token:$ROOT_TOKEN" -H "Content-Type: application/json" -X POST -d '{"username":"pvtest","password":""}' https://sva-vault.vault.svc.cluster.local:8200/v1/secret/basic-secret/helloworld #. Verify the secret. diff --git a/doc/source/security/kubernetes/create-an-admin-type-service-account.rst b/doc/source/security/kubernetes/create-an-admin-type-service-account.rst index dee7cee1e..0674b2e7f 100644 --- a/doc/source/security/kubernetes/create-an-admin-type-service-account.rst +++ b/doc/source/security/kubernetes/create-an-admin-type-service-account.rst @@ -23,24 +23,24 @@ an admin service account with cluster-admin role, use the following procedure: .. code-block:: none - % cat < joe-admin.yaml + % cat < admin-user.yaml apiVersion: v1 kind: ServiceAccount metadata: - name: joe-admin + name: admin-user namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: - name: joe-admin + name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount - name: joe-admin + name: admin-user namespace: kube-system EOF @@ -48,7 +48,7 @@ an admin service account with cluster-admin role, use the following procedure: .. code-block:: none - % kubectl apply -f joe-admin.yaml + % kubectl apply -f admin-user.yaml .. diff --git a/doc/source/security/kubernetes/create-ldap-linux-accounts.rst b/doc/source/security/kubernetes/create-ldap-linux-accounts.rst index 9fb867e04..d1dc7cc0a 100644 --- a/doc/source/security/kubernetes/create-ldap-linux-accounts.rst +++ b/doc/source/security/kubernetes/create-ldap-linux-accounts.rst @@ -6,24 +6,23 @@ Create LDAP Linux Accounts ========================== -|prod| includes a script for creating LDAP Linux accounts with built-in -Keystone user support. +|prod| includes a script for creating |LDAP| Linux accounts. .. rubric:: |context| -The :command:`ldapusersetup` command provides an interactive method for -setting up LDAP Linux user accounts with access to StarlingX commands. You -can assign a limited shell or a bash shell. +.. note:: + For security reasons, it is recommended that ONLY admin level users be + allowed to |SSH| to the nodes of the |prod|. Non-admin level users should + strictly use remote |CLIs| or remote web GUIs. -Users have the option of providing Keystone credentials at login, and can -establish or change Keystone credentials at any time during a session. -Keystone credentials persist for the duration of the session. +The :command:`ldapusersetup` command provides an interactive method for setting +up |LDAP| Linux user accounts. -Centralized management is implemented using two LDAP servers, one running on -each controller node. LDAP server synchronization is automatic using the -native LDAP content synchronization protocol. +Centralized management is implemented using two |LDAP| servers, one running on +each controller node. |LDAP| server synchronization is automatic using the +native |LDAP| content synchronization protocol. -A set of LDAP commands is available to operate on LDAP user accounts. The +A set of |LDAP| commands is available to operate on |LDAP| user accounts. The commands are installed in the directory /usr/local/sbin, and are available to any user account in the sudoers list. Included commands are :command:`lsldap`, :command:`ldapadduser`, :command:`ldapdeleteuser`, and @@ -43,18 +42,6 @@ as illustrated below. For convenience, identify the user's Keystone account user name in |prod-long|. -.. note:: - There is an M:M relationship between a Keystone user account and a user - Linux account. That is, the same Keystone user account may be used across - multiple Linux accounts. For example, the Keystone user **tenant user** - may be used by several Linux users, such as Kam, Greg, and Jim. - Conversely, contingent on the policy of the organization, 3 Keystone - cloud users \(Kam, Greg, and Jim\), may be used by a single Linux - account: **operator**. That is, Kam logs into |prod| with the - **operator** account, and sources Kam's Keystone user account. Jim does - the same and logs into |prod| with the **operator** account, but sources - Jim's Keystone user account. - .. rubric:: |proc| #. Log in as **sysadmin**, and start the :command:`ldapusersetup` script. @@ -70,39 +57,15 @@ For convenience, identify the user's Keystone account user name in |prod-long|. .. code-block:: none - Enter username to add to LDAP: - - For convenience, use the same name as the one assigned for the user's - Keystone account. \(This example uses **user1**\). When the LDAP user - logs in and establishes Keystone credentials, the LDAP user name is - offered as the default Keystone user name. + Enter username to add to |LDAP|: .. code-block:: none - Successfully added user user1 to LDAP + Successfully added user user1 to |LDAP| Successfully set password for user user1 - #. Specify whether to provide a limited shell or a bash shell. - - .. code-block:: none - - - Select Login Shell option # [2]: - 1) Bash - 2) Lshell - - To provide a limited shell with access to the StarlingX CLI only, - specify the Lshell option. - - If you select Bash, you are offered the option to add the user to the - sudoer list: - - .. code-block:: none - - Add user1 to sudoer list? (yes/No): - - #. Specify a secondary user group for this LDAP user. + #. Specify a secondary user group for this |LDAP| user. .. code-block:: none @@ -116,7 +79,7 @@ For convenience, identify the user's Keystone account user name in |prod-long|. .. code-block:: none - Successfully modified user entry uid=ldapuser1, ou=People, dc=cgcs, dc=local in LDAP + Successfully modified user entry uid=ldapuser1, ou=People, dc=cgcs, dc=local in |LDAP| Updating password expiry to 90 days #. Change the warning period before the password expires. @@ -139,7 +102,7 @@ On completion of the script, the command prompt is displayed. .. rubric:: |result| -The LDAP account is created. For information about the user login process, -see :ref:`Establish Keystone Credentials from a Linux Account -`. +The |LDAP| account is created. For information about the user login process, see +ref:`For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account +Login `. diff --git a/doc/source/security/kubernetes/deprovision-windows-active-directory-authentication.rst b/doc/source/security/kubernetes/deprovision-windows-active-directory-authentication.rst index 952237f67..f0e30c599 100644 --- a/doc/source/security/kubernetes/deprovision-windows-active-directory-authentication.rst +++ b/doc/source/security/kubernetes/deprovision-windows-active-directory-authentication.rst @@ -21,44 +21,44 @@ You can remove Windows Active Directory authentication from |prod-long|. .. code-block:: none - ~(keystone_admin)$ system service-parameter-list + ~(keystone_admin)]$ system service-parameter-list #. Delete each parameter. .. code-block:: none - ~(keystone_admin)$ system service-parameter-delete + ~(keystone_admin)]$ system service-parameter-delete #. Apply the changes. .. code-block:: none - ~(keystone_admin)$ system service-parameter-apply kubernetes + ~(keystone_admin)]$ system service-parameter-apply kubernetes #. Uninstall oidc-auth-apps. .. code-block:: none - ~(keystone_admin)$ system application-remove oidc-auth-apps + ~(keystone_admin)]$ system application-remove oidc-auth-apps #. Clear the helm-override configuration. .. code-block:: none - ~(keystone_admin)$ system helm-override-update oidc-auth-apps dex kube-system --reset-values - ~(keystone_admin)$ system helm-override-show oidc-auth-apps dex kube-system + ~(keystone_admin)]$ system helm-override-update oidc-auth-apps dex kube-system --reset-values + ~(keystone_admin)]$ system helm-override-show oidc-auth-apps dex kube-system - ~(keystone_admin)$ system helm-override-update oidc-auth-apps oidc-client kube-system --reset-values - ~(keystone_admin)$ system helm-override-show oidc-auth-apps oidc-client kube-system + ~(keystone_admin)]$ system helm-override-update oidc-auth-apps oidc-client kube-system --reset-values + ~(keystone_admin)]$ system helm-override-show oidc-auth-apps oidc-client kube-system #. Remove secrets that contain certificate data. .. code-block:: none - ~(keystone_admin)$ kubectl delete secret local-dex.tls -n kube-system - ~(keystone_admin)$ kubectl delete secret dex-client-secret -n kube-system - ~(keystone_admin)$ kubectl delete secret wadcert -n kube-system + ~(keystone_admin)]$ kubectl delete secret local-dex.tls -n kube-system + ~(keystone_admin)]$ kubectl delete secret dex-client-secret -n kube-system + ~(keystone_admin)]$ kubectl delete secret wadcert -n kube-system #. Remove any |RBAC| RoleBindings added for |OIDC| users and/or groups. diff --git a/doc/source/security/kubernetes/disable-pod-security-policy-checking.rst b/doc/source/security/kubernetes/disable-pod-security-policy-checking.rst index a5910a847..5de6b6ca9 100644 --- a/doc/source/security/kubernetes/disable-pod-security-policy-checking.rst +++ b/doc/source/security/kubernetes/disable-pod-security-policy-checking.rst @@ -16,12 +16,12 @@ disable pod security policy checking. .. code-block:: none - ~(keystone_admin)$ system service-parameter-delete + ~(keystone_admin)]$ system service-parameter-delete #. Apply the Kubernetes system parameters. .. code-block:: none - ~(keystone_admin)$ system service-parameter-apply kubernetes + ~(keystone_admin)]$ system service-parameter-apply kubernetes diff --git a/doc/source/security/kubernetes/enable-https-access-for-starlingx-rest-and-web-server-endpoints.rst b/doc/source/security/kubernetes/enable-https-access-for-starlingx-rest-and-web-server-endpoints.rst index ccd88f853..9493a0208 100644 --- a/doc/source/security/kubernetes/enable-https-access-for-starlingx-rest-and-web-server-endpoints.rst +++ b/doc/source/security/kubernetes/enable-https-access-for-starlingx-rest-and-web-server-endpoints.rst @@ -36,13 +36,13 @@ When secure HTTPS connectivity is enabled, HTTP is disabled. .. code-block:: none - ~(keystone_admin)$ system modify --https_enabled true + ~(keystone_admin)]$ system modify --https_enabled true - To disable HTTPS for StarlingX REST and Web Server endpoints: .. code-block:: none - ~(keystone_admin)$ system modify --https_enabled false + ~(keystone_admin)]$ system modify --https_enabled false - Use the following command to display HTTPS settings: diff --git a/doc/source/security/kubernetes/enable-pod-security-policy-checking.rst b/doc/source/security/kubernetes/enable-pod-security-policy-checking.rst index 8b713d806..11d57f760 100644 --- a/doc/source/security/kubernetes/enable-pod-security-policy-checking.rst +++ b/doc/source/security/kubernetes/enable-pod-security-policy-checking.rst @@ -13,13 +13,13 @@ Enable Pod Security Policy Checking .. code-block:: none - ~(keystone_admin)$ system service-parameter-add kubernetes kube_apiserver admission_plugins=PodSecurityPolicy + ~(keystone_admin)]$ system service-parameter-add kubernetes kube_apiserver admission_plugins=PodSecurityPolicy #. Apply the Kubernetes system parameters. .. code-block:: none - ~(keystone_admin)$ system service-parameter-apply kubernetes + ~(keystone_admin)]$ system service-parameter-apply kubernetes #. View the automatically added pod security policies. diff --git a/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst b/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst index 832a486dd..372310bb6 100644 --- a/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst +++ b/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst @@ -32,7 +32,7 @@ repository, see |admintasks-doc|: :ref:`Setting up a Public Repository .. code-block:: none - ~(keystone_admin)$ system registry-image-tags quay.io/jetstack/cert-manager-acmesolver + ~(keystone_admin)]$ system registry-image-tags quay.io/jetstack/cert-manager-acmesolver #. Copy the cert-manager-acmesolver image, and replace with the tag you want to copy from previous step. @@ -53,7 +53,7 @@ repository, see |admintasks-doc|: :ref:`Setting up a Public Repository .. code-block:: none - ~(keystone_admin)$ cat < cm-override-values.yaml + ~(keystone_admin)]$ cat < cm-override-values.yaml acmesolver: image: repository: registry.local:9001/public/cert-manager-acmesolver @@ -64,13 +64,13 @@ repository, see |admintasks-doc|: :ref:`Setting up a Public Repository .. code-block:: none - ~(keystone_admin)$ system helm-override-update --values cm-override-values.yaml cert-manager cert-manager cert-manager + ~(keystone_admin)]$ system helm-override-update --values cm-override-values.yaml cert-manager cert-manager cert-manager #. Reapply cert-manager. .. code-block:: none - ~(keystone_admin)$ system application-apply cert-manager + ~(keystone_admin)]$ system application-apply cert-manager diff --git a/doc/source/security/kubernetes/estabilish-credentials-for-linux-user-accounts.rst b/doc/source/security/kubernetes/estabilish-credentials-for-linux-user-accounts.rst new file mode 100644 index 000000000..f49137046 --- /dev/null +++ b/doc/source/security/kubernetes/estabilish-credentials-for-linux-user-accounts.rst @@ -0,0 +1,23 @@ + +.. ivt1613762759967 +.. _estabilish-credentials-for-linux-user-accounts: + +============================================= +Establish Credentials for Linux User Accounts +============================================= + +You can establish credentials for StarlingX, Platform OpenStack |CLIs|, and +Kubernetes |CLIs| \(kubectl and helm\) for Linux user accounts. + +For more information, see: + + +.. _estabilish-credentials-for-linux-user-accounts-ul-fjd-chd-s4b: + +- :ref:`For StarlingX, Platform OpenStack and Kubernetes CLIs from the 'sysadmin' Linux Account Login ` + +- :ref:`For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account Login ` + +- :ref:`For Kubernetes CLI from a Local LDAP Linux Account Login ` + + diff --git a/doc/source/security/kubernetes/establish-keystone-credentials-from-a-linux-account.rst b/doc/source/security/kubernetes/establish-keystone-credentials-from-a-linux-account.rst index 0cafa0878..2976fa73c 100644 --- a/doc/source/security/kubernetes/establish-keystone-credentials-from-a-linux-account.rst +++ b/doc/source/security/kubernetes/establish-keystone-credentials-from-a-linux-account.rst @@ -2,12 +2,13 @@ .. fan1552681866651 .. _establish-keystone-credentials-from-a-linux-account: -=================================================== -Establish Keystone Credentials from a Linux Account -=================================================== +=============================================================================== +For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account Login +=============================================================================== -The preferred method for establishing Keystone credentials is to log in to -an LDAP account created using :command:`ldapusersetup`. +You can establish Keystone credentials for executing StarlingX and Platform +OpenStack |CLIs| for a local |LDAP| user, if required; this is not setup by +default. .. contents:: :local: @@ -19,110 +20,43 @@ For more information about :command:`ldapusersetup`, see :ref:`Create LDAP Linux Accounts `. User accounts created using :command:`ldapusersetup` have access to the -Keystone CLI as part of the shell. To list the available commands, type -**?** at the command line: +StarlingX |CLIs| \(system, fm, sw-patch, dcmanager, etc.\) and the platform +'OpenStack' CLI as part of the shell. -.. code-block:: none +.. rubric:: |prereq| - user1@controller-0:~$ ? +.. _establish-keystone-credentials-from-a-linux-account-ul-qyv-fzm-ynb: - awk echo history ls pwd source cat clear - env grep keystone lsudo rm system cd cp - exit ll man openstack scp vim cut export - help lpath env passwd sftp kubectl helm +- You must have a platform Keystone user account. For more information about + creating Keystone users, managing keystone projects, users and roles, see + `https://docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html + `__. -When a user logs in to an account of this type, they are prompted to store -Keystone credentials for the duration of the session: +- It is recommended to use the same username for both your local |LDAP| user + and your Keystone user. -.. code-block:: none +.. rubric:: |context| - Pre-store Keystone user credentials for this session? (y/N):y +You can establish Keystone credentials, in order to use the StarlingX and +Platform OpenStack |CLIs|, using one of the following methods: -This invokes a script to obtain the credentials. The user can invoke the -same script at any time during the session as follows: +.. rubric:: |proc| -.. code-block:: none +.. _estabilish-keystone-credentials-from-a-linux-account-steps-hjs-dwm-ynb: - user1@controller-0:~$ source /home/sysadmin/lshell_env_setup +#. \(Method 1\) When you have logged into the Horizon Web interface with your + Keystone user credentials, download an OpenStack RC file \(openrc.sh\), and + use it to source the required environment within your local LDAP user shell + . For more information on downloading your OpenStack RC file from Horizon, + see, `http://docs.openstack.org `__. -Any Keystone credentials created by the script persist for the duration of -the session. This includes credentials added by previous invocations of the -script in the same session. +#. \(Method 2\) Add the required environment variables manually into a + wrcprc.sh file and use this to source the required environment within your + local |LDAP| user shell. -.. _establish-keystone-credentials-from-a-linux-account-section-N10079-N10020-N10001: - -------------------------------- -The Keystone Credentials Script -------------------------------- - -The Keystone credentials script offers the LDAP user name as the default -Keystone user name: - -.. code-block:: none - - Enter Keystone username [user1]: - -.. code-block:: none - - Enter Keystone user domain name: - -It requires the name of the tenant for which the user requires access: - -.. code-block:: none - - Enter Project name:tenant1 - .. note:: - The Keystone user must be a member of a Keystone tenant. This is - configured using Keystone. - -.. code-block:: none - - Enter Project domain name: - -It also requires the Keystone user password: - -.. code-block:: none - - Enter Keystone password: - -When the script is run during login, it sets the default **Keystone Region -Name** and **Keystone Authentication URL**. - -.. code-block:: none - - Selecting default Keystone Region Name: RegionOne - Selecting default Keystone Authentication URL: http://192.168.204.2:5000/v2.0/ - To re-configure your environment run "source ~/lshell_env_setup" in your shell - - Keystone credentials preloaded! - -If the script is run from the shell after login, it provides an option to -change the **Keystone Region Name** and **Keystone Authentication URL**. - - -.. _establishing-keystone-credentials-from-a-linux-account-section-N100B5-N10020-N10001: - ---------------------------------------------------------- -Alternative Methods for Establishing Keystone Credentials ---------------------------------------------------------- - -You can also establish Keystone credentials using the following methods: - - -.. _establish-keystone-credentials-from-a-linux-account-ul-scj-rch-t5: - -- Download an OpenStack RC file \(openrc.sh\) from the Horizon Web - interface, and use it to source the required environment. For more - information, refer to `http://docs.openstack.org - `__. - - .. note:: - Only users with bash shell can source the required environment. This - does not apply to users with limited shell. - -- Add the required environment variables manually: + For security and reliability, add all the variables. **OS\_USERNAME** the Keystone user name @@ -149,20 +83,4 @@ You can also establish Keystone credentials using the following methods: the interface **OS\_REGION\_NAME** - the Keystone Region Name - - For security and reliability, add all of the variables. - -- Provide credentials as command-line options. - - .. code-block:: none - - user1@controller-0:~$ system --os-username admin --os-password seeCaution host-list - - -.. caution:: - |org| does not recommend using the command-line option to provide - Keystone credentials. It creates a security risk, because the - supplied credentials are visible in the command-line history. - - + the Keystone Region Name \ No newline at end of file diff --git a/doc/source/security/kubernetes/https-access-overview.rst b/doc/source/security/kubernetes/https-access-overview.rst index 5b07dce2b..78e50d4e1 100644 --- a/doc/source/security/kubernetes/https-access-overview.rst +++ b/doc/source/security/kubernetes/https-access-overview.rst @@ -12,38 +12,19 @@ external |prod| service endpoints. These include: -.. - _https-access-overview-ul-eyn-5ln-gjb: +.. _https-access-overview-ul-eyn-5ln-gjb: -.. - - |prod| REST API applications and the |prod| web administration - server +- |prod| REST API applications and the |prod| web administration server -.. - - Kubernetes API +- Kubernetes API -.. - - Local Docker registry +- Local Docker registry .. contents:: :local: :depth: 1 -.. note:: - Only self-signed or Root |CA|-signed certificates are supported for the - above |prod| service endpoints. See `https://en.wikipedia.org/wiki/X.509 - `__ for an overview of root, - intermediate, and end-entity certificates. - -You can also add a trusted |CA| for the |prod| system. - -.. note:: - The default HTTPS X.509 certificates that are used by |prod-long| for - authentication are not signed by a known authority. For increased - security, obtain, install, and use certificates that have been signed by - a Root certificate authority. Refer to the documentation for the external - Root |CA| that you are using, on how to create public certificate and - private key pairs, signed by a Root |CA|, for HTTPS. +You can also add a trusted Certificate Authority \(CA\) for the |prod| system. .. _https-access-overview-section-N10048-N10024-N10001: @@ -63,11 +44,12 @@ REST and Web Server endpoints. In order to connect, remote clients must be configured to accept the self-signed certificate without verifying it. This is called insecure mode. -For secure-mode connections, a Root |CA|-signed certificate and key are -required. The use of a Root |CA|-signed certificate is strongly recommended. -Refer to the documentation for the external Root |CA| that you are using, on -how to create public certificate and private key pairs, signed by a Root |CA|, -for HTTPS. +For secure-mode connections, an intermediate or Root |CA|-signed certificate +and key are required. The use of an intermediate or Root |CA|-signed +certificate is strongly recommended. Refer to the documentation for the +external intermediate or Root |CA| that you are using, on how to create public +certificate and private key pairs, signed by an intermediate or Root |CA|, for +HTTPS. You can update the certificate and key used by |prod| for the REST and Web Server endpoints at any time after installation. @@ -84,15 +66,16 @@ hosts. Kubernetes ---------- -For the Kubernetes API Server, HTTPS is always enabled. Similarly, by -default, a self-signed certificate and key is generated and installed for -the Kubernetes Root |CA| certificate and key. This Kubernetes Root |CA| is -used to create and sign various certificates used within Kubernetes, -including the certificate used by the kube-apiserver API endpoint. +For the Kubernetes API Server, HTTPS is always enabled. You must use a Root CA +certificate; intermediate CA certificates are not supported by upstream +Kubernetes. By default, a self-signed certificate and key is generated and +installed for the Kubernetes Root |CA| certificate and key. This Kubernetes +Root |CA| is used to create and sign various certificates used within +Kubernetes, including the certificate used by the kube-apiserver API endpoint. -It is recommended that you update the Kubernetes Root |CA| and with a -custom Root |CA| certificate and key, generated by yourself, and trusted by -external servers connecting to |prod|'s Kubernetes API endpoint. |prod|'s +It is recommended that you update the Kubernetes Root |CA| and with a custom +Root |CA| certificate and key, generated by yourself, and trusted by your +external servers connecting to |prod|'s Kubernetes API endpoint. The |prod|'s Kubernetes Root |CA| is configured as part of the bootstrap during installation. @@ -103,13 +86,13 @@ installation. Local Docker Registry --------------------- -For the Local Docker Registry, HTTPS is always enabled. Similarly, by -default, a self-signed certificate and key is generated and installed for -this endpoint. However, it is recommended that you update the certificate -used after installation with a Root |CA|-signed certificate and key. Refer to -the documentation for the external Root |CA| that you are using, on how to -create public certificate and private key pairs, signed by a Root |CA|, for -HTTPS. +For the Local Docker Registry, HTTPS is always enabled. Similarly, by default, +a self-signed certificate and key is generated and installed for this endpoint. +However, it is recommended that you update the certificate used after +installation with an intermediate or Root |CA|-signed certificate and key. +Refer to the documentation for the external intermediate or Root |CA| that you +are using, on how to create public certificate and private key pairs, signed by +a Root |CA|, for HTTPS. .. _https-access-overview-section-N10086-N10024-N10001: diff --git a/doc/source/security/kubernetes/index.rst b/doc/source/security/kubernetes/index.rst index 5b1a8914c..5e1b5ebe7 100644 --- a/doc/source/security/kubernetes/index.rst +++ b/doc/source/security/kubernetes/index.rst @@ -9,7 +9,11 @@ System Accounts .. toctree:: :maxdepth: 1 + types-of-system-accounts overview-of-system-accounts + kube-service-account + keystone-accounts + remote-windows-active-directory-accounts Linux User Accounts ******************* @@ -23,6 +27,9 @@ Linux User Accounts remote-access-for-linux-accounts password-recovery-for-linux-user-accounts establish-keystone-credentials-from-a-linux-account + estabilish-credentials-for-linux-user-accounts + starlingx-openstack-kubernetes-from-stsadmin-account-login + kubernetes-cli-from-local-ldap-linux-account-login Kubernetes Service Accounts *************************** @@ -68,6 +75,7 @@ Access the System install-the-kubernetes-dashboard security-rest-api-access connect-to-container-registries-through-a-firewall-or-proxy + using-container-backed-remote-clis-and-clients *************************** Manage Non-Admin Type Users diff --git a/doc/source/security/kubernetes/install-portieris.rst b/doc/source/security/kubernetes/install-portieris.rst index 4789eb97c..1e7c491a5 100644 --- a/doc/source/security/kubernetes/install-portieris.rst +++ b/doc/source/security/kubernetes/install-portieris.rst @@ -20,7 +20,7 @@ You can install Portieris on |prod| from the command line. .. code-block:: none - ~(keystone_admin)$ system application-upload /usr/local/share/applications/helm/portieris-.tgz + ~(keystone_admin)]$ system application-upload /usr/local/share/applications/helm/portieris-.tgz #. Set caCert helm overrides if applicable. @@ -36,19 +36,19 @@ You can install Portieris on |prod| from the command line. .. code-block:: none - ~(keystone_admin)$ echo 'caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURYVENDQWtXZ0F3SUJBZ0lKQUpjVHBXcTk4SWNSTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4Q3pBSkJnTlYKQkFZVEFrRlZNUk13RVFZRFZRUUlEQXBUYjIxbExWTjBZWFJsTVNFd0h3WURWUVFLREJoSmJuUmxjbTVsZENCWAphV1JuYVhSeklGQjBlU0JNZEdRd0hoY05NVGd3T0RFMk1qQXlPREl3V2hjTk1qRXdOakExTWpBeU9ESXdXakJGCk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkRYwWlRFaE1COEdBMVVFQ2d3WVNXNTAKWlhKdVpYUWdWMmxrWjJsMGN5QlFkSGtnVEhSa01JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQgpDZ0tDQVFFQXV4YXJMaVdwMDVnbG5kTWRsL1o3QmhySDFPTFNTVTcwcm9mV3duTmNQS3hsOURmVVNWVTZMTDJnClppUTFVZnA4TzFlVTJ4NitPYUxxekRuc2xpWjIxdzNXaHRiOGp2NmRFakdPdTg3eGlWWDBuSDBmSjF3cHFBR0UKRkVXekxVR2dJM29aUDBzME1Sbm1xVDA4VWZ6S0hCaFgvekNvNHMyVm9NcWxRNyt0Qjc2dTA3V3NKYQ0RFlQVwprR2tFVmRMSk4rWWcwK0pLaisvVU9kbE5WNDB2OE1ocEhkbWhzY1QyakI3WSszT0QzeUNxZ1RjRzVDSDQvK3J6CmR4Qjk3dEpMM2NWSkRQWTVNQi9XNFdId2NKRkwzN1p1M0dVdmhmVGF3NVE0dS85cTFkczgrVGFYajdLbWUxSzcKQnYyMTZ5dTZiN3M1ckpHU2lEZ0p1TWFNcm5YajFRSURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVyQndhbTAreApydUMvY3Vpbkp1RlM4Y1ZibjBBd0h3WURWUjBqQkJnd0ZvQVVyQndhbTAreHJ1Qy9jdWluSnVGUzhjVmJuMEF3CkRBWURWUjBUQFVd0F3RUIvekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZzJ5aEFNazVJUlRvOWZLc1IvMXkKMXJ5NzdSWU5KN1R2dTB0clltRElBMVRaanFtanlncFFiSmlGb0FPa255eHYveURLU0x6TXFNU2JIb0I1K1BhSQpnTERub0F6SnYxbzg3OEpkVllURjIyS2RUTU5wNWtITXVGMnpSTFFxc2lvenJQSUpWMDlVb2VHeHpPQ1pkYzZBCnpUblpCSy9DVTlRcnhVdzhIeDV6SEFVcHdVcGxONUE4MVROUmlMYVFVTXB5dzQ4Y08wNFcyOWY1aFA2aGMwVDMKSDJpU212OWY2K3Q5TjBvTTFuWVh1blgwWNJZll1aERmQy83c3N3eDhWcW5uTlNMN0lkQkhodGxhRHJGRXBzdQpGZzZOODBCbGlDclJiN2FPcUk4TWNjdzlCZW9UUk9uVGxVUU5RQkEzTjAyajJvTlhYL2loVHQvZkhNYlZGUFRQCi9nPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' > caCert.yaml + ~(keystone_admin)]$ echo 'caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURYVENDQWtXZ0F3SUJBZ0lKQUpjVHBXcTk4SWNSTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4Q3pBSkJnTlYKQkFZVEFrRlZNUk13RVFZRFZRUUlEQXBUYjIxbExWTjBZWFJsTVNFd0h3WURWUVFLREJoSmJuUmxjbTVsZENCWAphV1JuYVhSeklGQjBlU0JNZEdRd0hoY05NVGd3T0RFMk1qQXlPREl3V2hjTk1qRXdOakExTWpBeU9ESXdXakJGCk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkRYwWlRFaE1COEdBMVVFQ2d3WVNXNTAKWlhKdVpYUWdWMmxrWjJsMGN5QlFkSGtnVEhSa01JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQgpDZ0tDQVFFQXV4YXJMaVdwMDVnbG5kTWRsL1o3QmhySDFPTFNTVTcwcm9mV3duTmNQS3hsOURmVVNWVTZMTDJnClppUTFVZnA4TzFlVTJ4NitPYUxxekRuc2xpWjIxdzNXaHRiOGp2NmRFakdPdTg3eGlWWDBuSDBmSjF3cHFBR0UKRkVXekxVR2dJM29aUDBzME1Sbm1xVDA4VWZ6S0hCaFgvekNvNHMyVm9NcWxRNyt0Qjc2dTA3V3NKYQ0RFlQVwprR2tFVmRMSk4rWWcwK0pLaisvVU9kbE5WNDB2OE1ocEhkbWhzY1QyakI3WSszT0QzeUNxZ1RjRzVDSDQvK3J6CmR4Qjk3dEpMM2NWSkRQWTVNQi9XNFdId2NKRkwzN1p1M0dVdmhmVGF3NVE0dS85cTFkczgrVGFYajdLbWUxSzcKQnYyMTZ5dTZiN3M1ckpHU2lEZ0p1TWFNcm5YajFRSURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVyQndhbTAreApydUMvY3Vpbkp1RlM4Y1ZibjBBd0h3WURWUjBqQkJnd0ZvQVVyQndhbTAreHJ1Qy9jdWluSnVGUzhjVmJuMEF3CkRBWURWUjBUQFVd0F3RUIvekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZzJ5aEFNazVJUlRvOWZLc1IvMXkKMXJ5NzdSWU5KN1R2dTB0clltRElBMVRaanFtanlncFFiSmlGb0FPa255eHYveURLU0x6TXFNU2JIb0I1K1BhSQpnTERub0F6SnYxbzg3OEpkVllURjIyS2RUTU5wNWtITXVGMnpSTFFxc2lvenJQSUpWMDlVb2VHeHpPQ1pkYzZBCnpUblpCSy9DVTlRcnhVdzhIeDV6SEFVcHdVcGxONUE4MVROUmlMYVFVTXB5dzQ4Y08wNFcyOWY1aFA2aGMwVDMKSDJpU212OWY2K3Q5TjBvTTFuWVh1blgwWNJZll1aERmQy83c3N3eDhWcW5uTlNMN0lkQkhodGxhRHJGRXBzdQpGZzZOODBCbGlDclJiN2FPcUk4TWNjdzlCZW9UUk9uVGxVUU5RQkEzTjAyajJvTlhYL2loVHQvZkhNYlZGUFRQCi9nPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' > caCert.yaml #. Apply the override file. .. code-block:: none - ~(keystone_admin)$ system helm-override-update portieris portieris-certs portieris --values caCert.yaml + ~(keystone_admin)]$ system helm-override-update portieris portieris-certs portieris --values caCert.yaml #. Apply the application. .. code-block:: none - ~(keystone_admin)$ system application-apply portieris + ~(keystone_admin)]$ system application-apply portieris diff --git a/doc/source/security/kubernetes/install-the-kubernetes-dashboard.rst b/doc/source/security/kubernetes/install-the-kubernetes-dashboard.rst index e42c8568a..ea5ecf614 100644 --- a/doc/source/security/kubernetes/install-the-kubernetes-dashboard.rst +++ b/doc/source/security/kubernetes/install-the-kubernetes-dashboard.rst @@ -29,7 +29,7 @@ Dashboard. .. code-block:: none - ~(keystone_admin)$ kubectl create namespace kubernetes-dashboard + ~(keystone_admin)]$ kubectl create namespace kubernetes-dashboard #. Create a certificate for use by the Kubernetes Dashboard. @@ -43,20 +43,20 @@ Dashboard. .. code-block:: none - ~(keystone_admin)$ cd /home/sysadmin - ~(keystone_admin)$ mkdir -p /home/sysadmin/kube/dashboard/certs + ~(keystone_admin)]$ cd /home/sysadmin + ~(keystone_admin)]$ mkdir -p /home/sysadmin/kube/dashboard/certs #. Create the certificate. .. code-block:: none - ~(keystone_admin)$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /home/sysadmin/kube/dashboard/certs/dashboard.key -out /home/sysadmin/kube/dashboard/certs/dashboard.crt -subj "/CN=" + ~(keystone_admin)]$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /home/sysadmin/kube/dashboard/certs/dashboard.key -out /home/sysadmin/kube/dashboard/certs/dashboard.crt -subj "/CN=" where: **** - The fully qualified domain name for the |prod| cluster's OAM floating IP. + The fully qualified domain name for the |prod| cluster's |OAM| floating IP. #. Create a kubernetes secret for holding the certificate and private key. @@ -73,7 +73,7 @@ Dashboard. .. code-block:: none - ~(keystone_admin)$ wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml + ~(keystone_admin)]$ wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml #. Edit the file. @@ -98,18 +98,18 @@ Dashboard. .. code-block:: none - ~(keystone_admin)$ kubectl apply -f recommended.yaml + ~(keystone_admin)]$ kubectl apply -f recommended.yaml #. Patch the kubernetes dashboard service to type=NodePort and port=30000. .. code-block:: none - ~(keystone_admin)$ kubectl patch service kubernetes-dashboard -n kubernetes-dashboard -p '{"spec":{"type":"NodePort","ports":[{"port":443, "nodePort":30000}]}}' + ~(keystone_admin)]$ kubectl patch service kubernetes-dashboard -n kubernetes-dashboard -p '{"spec":{"type":"NodePort","ports":[{"port":443, "nodePort":30000}]}}' #. Test the Kubernetes Dashboard deployment. The Kubernetes Dashboard is listening at port 30000 on the machine - defined above for |prod| cluster's OAM floating IP. + defined above for |prod| cluster's |OAM| floating IP. #. Access the dashboard at https://:30000 diff --git a/doc/source/security/kubernetes/install-update-the-starlingx-rest-and-web-server-certificate.rst b/doc/source/security/kubernetes/install-update-the-starlingx-rest-and-web-server-certificate.rst index 426860ee5..5814886ff 100644 --- a/doc/source/security/kubernetes/install-update-the-starlingx-rest-and-web-server-certificate.rst +++ b/doc/source/security/kubernetes/install-update-the-starlingx-rest-and-web-server-certificate.rst @@ -12,16 +12,18 @@ administration server. .. rubric:: |prereq| -Obtain a Root |CA|-signed certificate and key from a trusted Root |CA|. -Refer to the documentation for the external Root |CA| that you are using, -on how to create public certificate and private key pairs, signed by a Root -|CA|, for HTTPS. +Obtain an intermediate or Root |CA|-signed certificate and key from a trusted +intermediate or Root |CA|. Refer to the documentation for the external +Intermediate or Root |CA| that you are using, on how to create public +certificate and private key pairs, signed by intermediate or a Root |CA|, for +HTTPS. .. xbooklink For lab purposes, see :ref:`Locally Creating Certificates ` for how to create a test - Root |CA| certificate and key, and use it to sign test certificates. + intermediate or Root |CA| certificate and key, and use it to sign test + certificates. Put the |PEM| encoded versions of the certificate and key in a single file, and copy the file to the controller host. @@ -34,13 +36,13 @@ and copy the file to the controller host. .. code-block:: none - ~(keystone_admin)$ system certificate-install + ~(keystone_admin)]$ system certificate-install -m ssl where: **** - is the path to the file containing both the Root |CA|-signed certificate - and private key to install. + is the path to the file containing both the intermediate or Root + |CA|-signed certificate and private key to install. diff --git a/doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst b/doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst index 7b681d987..d073277ca 100644 --- a/doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst +++ b/doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst @@ -10,7 +10,7 @@ Isolate StarlingX's Internal Cloud Management Network only the hosts on the cluster. For information on internal networks, see the :ref:`StarlingX Planning Guide -`. The network should be configured as a -private network visible to only the hosts on the cluster. Proper switch -configuration is required to achieve the isolation. +` should be configured as a private network +visible to only the hosts on the cluster. Proper switch configuration is +required to achieve the isolation. diff --git a/doc/source/security/kubernetes/keystone-accounts.rst b/doc/source/security/kubernetes/keystone-accounts.rst new file mode 100644 index 000000000..9b9860c69 --- /dev/null +++ b/doc/source/security/kubernetes/keystone-accounts.rst @@ -0,0 +1,14 @@ + +.. xsx1607977134022 +.. _keystone-accounts: + +================= +Keystone Accounts +================= + +|prod-long| uses Keystone for authentication and authorization of users of the +StarlingX REST APIs, the |CLI|, the Horizon Web interface and the Local Docker +Registry. |prod|'s Keystone uses the default local SQL Backend. + +See :ref:`About Keystone Accounts ` for more details. + diff --git a/doc/source/security/kubernetes/kube-service-account.rst b/doc/source/security/kubernetes/kube-service-account.rst new file mode 100644 index 000000000..e087f0b5f --- /dev/null +++ b/doc/source/security/kubernetes/kube-service-account.rst @@ -0,0 +1,14 @@ + +.. lpl1607977081524 +.. _kube-service-account: + +=========================== +Kubernetes Service Accounts +=========================== + +|prod| uses Kubernetes service accounts and |RBAC| policies for authentication +and authorization of users of the Kubernetes API, |CLI|, and Dashboard. + +See :ref:`Kubernetes Service Accounts ` for more +details. + diff --git a/doc/source/security/kubernetes/kubernetes-cli-from-local-ldap-linux-account-login.rst b/doc/source/security/kubernetes/kubernetes-cli-from-local-ldap-linux-account-login.rst new file mode 100644 index 000000000..0c906621b --- /dev/null +++ b/doc/source/security/kubernetes/kubernetes-cli-from-local-ldap-linux-account-login.rst @@ -0,0 +1,62 @@ + +.. zmz1607701719511 +.. _kubernetes-cli-from-local-ldap-linux-account-login: + +======================================================== +For Kubernetes CLI from a Local LDAP Linux Account Login +======================================================== + +You can establish credentials for executing Kubernetes |CLIs| \(kubectl and +helm\) for a Local |LDAP| user, if required; this is not setup by default. + +.. rubric:: |context| + +For more information about :command:`ldapusersetup`, see :ref:`Creating LDAP +Linux Accounts `. + +.. rubric:: |prereq| + +.. _kubernetes-cli-from-local-ldap-linux-account-login-ul-afg-rcn-ynb: + +- You must have a Kubernetes Service Account. + +- See :ref:`Creating an Admin Type Service Account + ` for details on how to create an admin + level service account. For more clarifications, ask your 'sysadmin'. + +.. rubric:: |context| + +It is recommended to use the same username for both your Local |LDAP| user and +your Kubernetes Service Account. + +.. rubric:: |proc| + +#. Add your Local |LDAP| user account to the 'root' group in order to get + access to execute :command:`kubectl`. + + If you have sudo permissions, run the following command first, and then + re-ssh to your local |LDAP| user account, otherwise the 'sysadmin' will have + to execute this step. + + .. code-block:: none + + $sudo usermod -a -G root + +#. Configure :command:`kubectl` access. + + .. note:: + Your 'sysadmin' should have given you a TOKEN while setting up your + Kubernetes Service Account. + + Execute the following commands: + + .. code-block:: none + + $ kubectl config set-cluster mycluster --server=https://192.168.206.1:6443 --insecure-skip-tls-verify + $ kubectl config set-credentials joe-admin@mycluster --token=$TOKEN + $ kubectl config set-context joe-admin@mycluster --cluster=mycluster --user joe-admin@mycluster + $ kubectl config use-context joe-admin@mycluster + + You now have admin access to |prod| Kubernetes cluster. + + diff --git a/doc/source/security/kubernetes/kubernetes-root-ca-certificate.rst b/doc/source/security/kubernetes/kubernetes-root-ca-certificate.rst index cefdb768e..c37a1ed1c 100644 --- a/doc/source/security/kubernetes/kubernetes-root-ca-certificate.rst +++ b/doc/source/security/kubernetes/kubernetes-root-ca-certificate.rst @@ -20,6 +20,18 @@ servers connecting to the |prod|'s Kubernetes API endpoint. ` for how to create a private Root |CA| certificate and key. +.. caution:: + The default duration for the generated Kubernetes Root CA certificate is 10 + years. Replacing the Root |CA| certificate is a complex process, so the custom + certificate expiry should be set for a long period, if possible. Wind River + recommends setting the Root |CA| certificate with an expiry of at least 5-10 + years. + + The administrator can also provide values to add to the Kubernetes API + server certificate **Subject Alternative Name** list using the + apiserver\_cert\_sans override parameter. + + Use the bootstrap override values and , as part of the installation procedure to specify the certificate and key for the Kubernetes root |CA|. @@ -74,6 +86,8 @@ associated with the |OAM| floating IP address should be added. Make the K8S Root |CA| certificate available to any remote server wanting to connect remotely to the |prod|'s Kubernetes API, e.g. through kubectl or helm. +This Kubernetes Root CA certificate should be configured as a trusted |CA| on +the remote server. See the step :ref:`2.b ` in diff --git a/doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst b/doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst index 8ac1d6ec6..6fc2c3ef7 100644 --- a/doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst +++ b/doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst @@ -12,22 +12,19 @@ cluster using standard Linux commands. .. _local-and-ldap-linux-user-accounts-ul-zrv-zwf-mmb: -Local Linux user accounts should NOT be configured, only use local LDAP -accounts for internal system purposes that would usually not be created by -an end-user. +- Local Linux user accounts should NOT be configured, only use local |LDAP| + accounts for internal system purposes that would usually not be created by + an end-user. -Password changes are not enforced automatically on the first login, and -they are not propagated by the system \(only for 'sysadmin'\). +- Password changes are not enforced automatically on the first login, and + they are not propagated by the system \(only for 'sysadmin'\). -.. note:: - If the administrator wants to provision additional access to the - system, it is better to configure local LDAP Linux accounts. +- **If the administrator wants to provision additional access to the system, it is better to configure local LDAP Linux accounts.** - -- LDAP accounts are centrally managed; changes made on any host are +- |LDAP| accounts are centrally managed; changes made on any host are propagated automatically to all hosts on the cluster. -- LDAP user accounts behave as any local user account. They can be added +- |LDAP| user accounts behave as any local user account. They can be added to the sudoers list and can acquire OpenStack administration credentials. - The initial password must be changed immediately upon the first login. @@ -42,11 +39,10 @@ they are not propagated by the system \(only for 'sysadmin'\). of the target host. - .. note:: - For security reasons, it is recommended that ONLY admin level users - be allowed to SSH to the nodes of |prod|. Non-admin level users - should strictly use remote CLIs or remote web GUIs. + For security reasons, it is recommended that ONLY admin level users be + allowed to |SSH| to the nodes of the |prod|. Non-admin level users should + strictly use remote |CLIs| or remote web GUIs. Operational complexity: @@ -54,14 +50,14 @@ Operational complexity: - Passwords aging is automatically configured. -- LDAP user accounts \(operator, admin\) are available by default on +- |LDAP| user accounts \(operator, admin\) are available by default on newly deployed hosts. For increased security, the admin and operator - accounts must be used from the console ports of the hosts; no SSH access is - allowed. + accounts must be used from the console ports of the hosts; no |SSH| access + is allowed. -- |prod| includes a script for creating LDAP Linux accounts with built-in +- |prod| includes a script for creating |LDAP| Linux accounts with built-in Keystone user support. It provides an interactive method for setting up - LDAP Linux user accounts with access to OpenStack commands. You can assign - a limited shell or a bash shell. + |LDAP| Linux user accounts with access to OpenStack commands. You can + assign a limited shell or a bash shell. diff --git a/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst b/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst index 92d86e52d..4f091ad37 100644 --- a/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst +++ b/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst @@ -19,9 +19,10 @@ accounts \(in addition to sysadmin\) that can SSH to the nodes of the |prod|. allowed to SSH to the nodes of the |prod|. Non-admin level users should strictly use remote CLIs or remote web GUIs. -Apart from being centrally managed, LDAP user accounts behave as any local -user account. They can be added to the sudoers list, and can acquire -Keystone administration credentials when executing on the active controller. +Apart from being centrally managed, LDAP user accounts behave as any local user +account. They can be added to the sudoers list, and can acquire Keystone +administration credentials, Kubernetes kubectl, and helm administrative +commands as the Kubernetes admin user, when executing on the active controller. LDAP user accounts share the following set of attributes: @@ -50,6 +51,12 @@ LDAP user accounts share the following set of attributes: and are local to that host. +.. _local-ldap-linux-user-accounts-section-kts-bvh-ynb: + +-------------------------- +Default LDAP User Accounts +-------------------------- + The following LDAP user accounts are available by default on newly deployed hosts, regardless of their personality: @@ -57,9 +64,9 @@ hosts, regardless of their personality: A cloud administrative account, comparable to the default **admin** account used in the web management interface. - This user account operates on a restricted Linux shell, with very - limited access to native Linux commands. However, the shell is - preconfigured to have administrative access to StarlingX commands. + This user account has access to all native Linux commands not requiring + root or sudo privileges, and it's shell is preconfigured to have + administrative access to StarlingX commands. **admin** A host administrative account. It has access to all native Linux @@ -80,4 +87,6 @@ from the console ports of the hosts; no SSH access is allowed. **operator** account enables access to the cloud deployment only, without giving unabated sudo access to the entire system. +.. seealso:: + :ref:`Creating LDAP Linux Accounts ` \ No newline at end of file diff --git a/doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst b/doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst index 06b738914..7730a3fb3 100644 --- a/doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst +++ b/doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst @@ -6,11 +6,11 @@ Local Linux Account for 'sysadmin' ================================== -This is a local, per-host, sudo-enabled account created automatically when -a new host is provisioned. +This is a local, per-host, sudo-enabled account created automatically when a +new host is provisioned. -This Linux user account is used by the system administrator as it has -extended privileges. +This Linux user account is used by the system administrator as it has extended +privileges. .. _local-linux-account-for-sysadmin-ul-zgk-1wf-mmb: @@ -21,8 +21,7 @@ extended privileges. - After five consecutive unsuccessful login attempts, further attempts are blocked for about five minutes. -Operational complexity: None. - -The above security hardening features are set by default \(see :ref:`System -Account Password Rules ` for password rules\). +Operational complexity: None. The above security hardening features are set by +default \(see :ref:`System Account Password Rules +` for password rules\). diff --git a/doc/source/security/kubernetes/manage-keystone-accounts.rst b/doc/source/security/kubernetes/manage-keystone-accounts.rst index 438b779dd..147492835 100644 --- a/doc/source/security/kubernetes/manage-keystone-accounts.rst +++ b/doc/source/security/kubernetes/manage-keystone-accounts.rst @@ -11,21 +11,30 @@ See `_ _ for details on managing Keystone projects, users, and roles. -.. note:: - All Kubernetes accounts are subject to system password rules. For - complete details on password rules, see :ref:`System Account Password - Rules `. + +All Kubernetes accounts are subject to system password rules. For complete +details on password rules, see :ref:`System Account Password Rules +`. + +If you are using when changing the keystone 'admin' user password, you must: .. _managing-keystone-accounts-ol-wyq-l4d-mmb: -If using the FIXME: REMOVE, when changing the Keystone 'admin' user -password, you must: +#. If the **deployment-config.yaml** file has been moved off-box for security + reasons, upload the file back to the system to be updated. -#. Update the password in the 'system-endpoint' secret in the FIXME: - REMOVE's deployment-config.yaml file, with the new Keystone 'admin' - user password. + .. warning:: + The **deployment-config.yaml** file includes sensitive information + \(including system credentials and passwords\). For increased security, + it is recommended to store the **deployment-config.yaml** in a safe + location off-box. Upload the file to the system only when it is + required \(during initial configuration, and when reapplying an updated + configuration\). - Make this change to the OS\_PASSWORD value. It must be base64 encoded. For example: +#. Update the password in the 'system-endpoint' secret in the 's + deployment-config.yaml file, with the new keystone 'admin' user password. + Make this change to the OS\_PASSWORD value. It must be base64 encoded. For + example: .. code-block:: none @@ -37,4 +46,5 @@ password, you must: kubectl apply -f deployment-config.yaml - +#. \(Optional\) For security reasons, copy the updated + **deployment-config.yaml** file off-box and delete it from the system. diff --git a/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-browser.rst b/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-browser.rst index d579ff90d..2cec04a19 100644 --- a/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-browser.rst +++ b/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-browser.rst @@ -64,21 +64,21 @@ refresh-token using the **oidc-auth-apps** |OIDC| client web interface. .. code-block:: none - ~(keystone_admin)$ TOKEN= - ~(keystone_admin)$ kubectl config set-credentials testuser --token $TOKEN + ~(keystone_admin)]$ TOKEN= + ~(keystone_admin)]$ kubectl config set-credentials testuser --token $TOKEN #. Switch to the Kubernetes context for the user, by using the following command, for example: .. code-block:: none - ~(keystone_admin)$ kubectl config use-context testuser@mywrcpcluster + ~(keystone_admin)]$ kubectl config use-context testuser@mywrcpcluster #. Run the following command to test that the authentication token validates correctly: .. code-block:: none - ~(keystone_admin)$ kubectl get pods --all-namespaces + ~(keystone_admin)]$ kubectl get pods --all-namespaces diff --git a/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-oidc-auth-shell-script.rst b/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-oidc-auth-shell-script.rst index a7e80f8e8..9141baedf 100644 --- a/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-oidc-auth-shell-script.rst +++ b/doc/source/security/kubernetes/obtain-the-authentication-token-using-the-oidc-auth-shell-script.rst @@ -59,13 +59,13 @@ credential for the user in the **kubectl** config file. .. code-block:: none - ~(keystone_admin)$ oidc-auth -c -u + ~(keystone_admin)]$ oidc-auth -c -u For example, .. code-block:: none - ~(keystone_admin)$ oidc-auth -c -u testuser + ~(keystone_admin)]$ oidc-auth -c -u testuser Password: Login succeeded. Updating kubectl config ... @@ -75,7 +75,7 @@ credential for the user in the **kubectl** config file. .. code-block:: none - ~(keystone_admin)$ oidc-auth -b -c -u + ~(keystone_admin)]$ oidc-auth -b -c -u diff --git a/doc/source/security/kubernetes/overview-of-system-accounts.rst b/doc/source/security/kubernetes/overview-of-system-accounts.rst index d456f5922..35d72a916 100644 --- a/doc/source/security/kubernetes/overview-of-system-accounts.rst +++ b/doc/source/security/kubernetes/overview-of-system-accounts.rst @@ -2,71 +2,34 @@ .. lgd1552571882796 .. _overview-of-system-accounts: -===================================== -Overview of StarlingX System Accounts -===================================== +================== +Linux UserAccounts +================== A brief description of the system accounts available in a |prod| system. -.. _overview-of-system-accounts-section-N1001F-N1001C-N10001: +**Sysadmin Local Linux Account** + This is a local, per-host, sudo-enabled account created automatically when + a new host is provisioned. It is used by the primary system administrator + for |prod|, as it has extended privileges. ------------------------- -Types of System Accounts ------------------------- + See :ref:`The sysadmin Account ` for more details. -- **sysadmin Local Linux Account** - This is a local, per-host, account created automatically when a new host - is provisioned. This account has extended privileges and is used by the - system administrator. +**Local Linux User Accounts** + Local Linux User Accounts should NOT be created since they are used for + internal system purposes. -- **Local Linux User Accounts** - These are local, regular Linux user accounts that are typically used for - internal system purposes and generally should not be created by an end - user. +**Local LDAP Linux User Accounts** + These are local LDAP accounts that are centrally managed across all hosts + in the cluster. These accounts are intended to provide additional admin + level user accounts \(in addition to sysadmin\) that can SSH to the nodes + of the |prod|. - If the administrator wants to provision additional access to the system, - it is better to configure local LDAP Linux accounts. - -- **Local LDAP Linux User Accounts** - |prod| provides support for Local Ldap Linux User Accounts. Local LDAP - accounts are centrally managed; changes to local LDAP accounts made on - any host are propagated automatically to all hosts on the cluster. - - |prod| includes a set of scripts for creating LDAP Linux accounts with - support for providing Keystone user account credentials. \(The scripts do - not create Keystone accounts for you. The scripts allow for sourcing or - accessing the Keystone user account credentials.\) - - The intended use of these accounts is to provide additional admin level - user accounts \(in addition to sysadmin\) that can SSH to the nodes of - the |prod|. + See :ref:`Local LDAP Linux User Accounts ` + for more details. .. note:: - For security reasons, it is recommended that ONLY admin level users - be allowed to SSH to the nodes of the |prod|. Non-admin level users - should strictly use remote CLIs or remote web GUIs.. - - These Local LDAP Linux user accounts can be associated with a Keystone - account. You can use the provided scripts to create these Local LDAP - Linux user accounts and synchronize them with the credentials of an - associated Keystone account, so that the Linux user can leverage - StarlingX CLI commands. - -- **Kubernetes Service Accounts** - |prod| uses Kubernetes service accounts and |RBAC| policies for - authentication and authorization of users of the Kubernetes API, CLI, and - Dashboard. - -- **Keystone Accounts** - |prod-long| uses Keystone for authentication and authorization of users - of the StarlingX REST APIs, the CLI, the Horizon Web interface and the - Local Docker Registry. |prod|'s Keystone uses the default local SQL - Backend. - -- **Remote Windows Active Directory Accounts** - |prod| can optionally be configured to use remote Windows Active - Directory Accounts and native Kubernetes |RBAC| policies for - authentication and authorization of users of the Kubernetes API, - CLI, and Dashboard. - + For security reasons, it is recommended that ONLY admin level users be + allowed to |SSH| to the nodes of the |prod|. Non-admin level users should + strictly use remote |CLIs| or remote web GUIs. diff --git a/doc/source/security/kubernetes/password-recovery.rst b/doc/source/security/kubernetes/password-recovery.rst index 7fe51a871..72f6430ea 100644 --- a/doc/source/security/kubernetes/password-recovery.rst +++ b/doc/source/security/kubernetes/password-recovery.rst @@ -6,6 +6,10 @@ Password Recovery ================= +.. rubric:: |context| + +This section describes how to change or reset a Keystone user password. + .. rubric:: |proc| - Do one of the following to change a Keystone admin user password at any @@ -18,7 +22,7 @@ Password Recovery .. code-block:: none - ~(keystone_admin)$ openstack user password set + ~(keystone_admin)]$ openstack user password set .. warning:: Both controller nodes must be locked and unlocked after changing @@ -30,7 +34,7 @@ Password Recovery .. code-block:: none - ~(keystone_admin)$ openstack user set --password + ~(keystone_admin)]$ openstack user set --password where is the username and is a temporary password. diff --git a/doc/source/security/kubernetes/remote-access-for-linux-accounts.rst b/doc/source/security/kubernetes/remote-access-for-linux-accounts.rst index 452b450f3..fa99bcc96 100644 --- a/doc/source/security/kubernetes/remote-access-for-linux-accounts.rst +++ b/doc/source/security/kubernetes/remote-access-for-linux-accounts.rst @@ -6,15 +6,16 @@ Remote Access for Linux Accounts ================================ -You can log in remotely as a Linux user using :command:`ssh`. +You can log in remotely as a Linux user\(either sysadmin or a local |LDAP| +user\) using :command:`ssh`. .. note:: For security reasons, it is recommended that ONLY admin level users be - allowed to SSH to the nodes of the |prod|. Non-admin level users should - strictly use remote CLIs or remote web GUIs. + allowed to |SSH| to the nodes of the |prod|. Non-admin level users should + strictly use remote |CLIs| or remote web GUIs. -Specifying the OAM floating IP address as the target establishes a -connection to the currently active controller; however, if the OAM floating +Specifying the |OAM| floating IP address as the target establishes a +connection to the currently active controller; however, if the |OAM| floating IP address moves from one controller node to another, the ssh session is blocked. To ensure access to a particular controller regardless of its current role, specify the controller physical address instead. diff --git a/doc/source/security/kubernetes/remote-windows-active-directory-accounts.rst b/doc/source/security/kubernetes/remote-windows-active-directory-accounts.rst new file mode 100644 index 000000000..529fe32f1 --- /dev/null +++ b/doc/source/security/kubernetes/remote-windows-active-directory-accounts.rst @@ -0,0 +1,15 @@ + +.. yda1607977206655 +.. _remote-windows-active-directory-accounts: + +======================================== +Remote Windows Active Directory Accounts +======================================== + +|prod| can optionally be configured to use remote Windows Active Directory +Accounts and native Kubernetes |RBAC| policies for authentication and +authorization of users of the Kubernetes API, |CLI|, and Dashboard. + +See :ref:`User Authentication Using Windows Active Directory +` for more details. + diff --git a/doc/source/security/kubernetes/remove-portieris.rst b/doc/source/security/kubernetes/remove-portieris.rst index 5f7b567ea..6d8ed0dce 100644 --- a/doc/source/security/kubernetes/remove-portieris.rst +++ b/doc/source/security/kubernetes/remove-portieris.rst @@ -15,7 +15,7 @@ system. .. code-block:: none - ~(keystone_admin)$ system application-remove portieris + ~(keystone_admin)]$ system application-remove portieris #. Delete kubernetes resources not automatically removed in the previous step. @@ -23,11 +23,11 @@ system. .. code-block:: none - ~(keystone_admin)$ kubectl delete clusterroles.rbac.authorization.k8s.io portieris - ~(keystone_admin)$ kubectl delete clusterrolebindings.rbac.authorization.k8s.io admission-portieris-webhook - ~(keystone_admin)$ kubectl delete -n portieris secret/portieris-certs - ~(keystone_admin)$ kubectl delete -n portieris cm/image-policy-crds - ~(keystone_admin)$ kubectl delete -n portieris serviceaccounts/portieris + ~(keystone_admin)]$ kubectl delete clusterroles.rbac.authorization.k8s.io portieris + ~(keystone_admin)]$ kubectl delete clusterrolebindings.rbac.authorization.k8s.io admission-portieris-webhook + ~(keystone_admin)]$ kubectl delete -n portieris secret/portieris-certs + ~(keystone_admin)]$ kubectl delete -n portieris cm/image-policy-crds + ~(keystone_admin)]$ kubectl delete -n portieris serviceaccounts/portieris .. note:: If this step is done before removing the application in step 1, the @@ -37,19 +37,19 @@ system. .. code-block:: none - ~(keystone_admin)$ kubectl delete MutatingWebhookConfiguration image-admission-config --ignore-not-found=true - ~(keystone_admin)$ kubectl delete ValidatingWebhookConfiguration image-admission-config --ignore-not-found=true - ~(keystone_admin)$ kubectl delete crd clusterimagepolicies.securityenforcement.admission.cloud.ibm.com imagepolicies.securityenforcement.admission.cloud.ibm.com --ignore-not-found=true - ~(keystone_admin)$ kubectl delete clusterroles.rbac.authorization.k8s.io portieris --ignore-not-found=true - ~(keystone_admin)$ kubectl delete clusterrolebindings.rbac.authorization.k8s.io admission-portieris-webhook --ignore-not-found=true - ~(keystone_admin)$ kubectl delete ns/portieris --ignore-not-found=true - ~(keystone_admin)$ helm delete portieris-portieris --purge --no-hooks - ~(keystone_admin)$ system application-remove portieris + ~(keystone_admin)]$ kubectl delete MutatingWebhookConfiguration image-admission-config --ignore-not-found=true + ~(keystone_admin)]$ kubectl delete ValidatingWebhookConfiguration image-admission-config --ignore-not-found=true + ~(keystone_admin)]$ kubectl delete crd clusterimagepolicies.securityenforcement.admission.cloud.ibm.com imagepolicies.securityenforcement.admission.cloud.ibm.com --ignore-not-found=true + ~(keystone_admin)]$ kubectl delete clusterroles.rbac.authorization.k8s.io portieris --ignore-not-found=true + ~(keystone_admin)]$ kubectl delete clusterrolebindings.rbac.authorization.k8s.io admission-portieris-webhook --ignore-not-found=true + ~(keystone_admin)]$ kubectl delete ns/portieris --ignore-not-found=true + ~(keystone_admin)]$ helm delete portieris-portieris --purge --no-hooks + ~(keystone_admin)]$ system application-remove portieris #. Delete the application. .. code-block:: none - ~(keystone_admin)$ system application-delete portieris + ~(keystone_admin)]$ system application-delete portieris diff --git a/doc/source/security/kubernetes/secure-starlingx-rest-and-web-certificates-private-key-storage-with-tpm.rst b/doc/source/security/kubernetes/secure-starlingx-rest-and-web-certificates-private-key-storage-with-tpm.rst index 797165bf7..2bef2de55 100644 --- a/doc/source/security/kubernetes/secure-starlingx-rest-and-web-certificates-private-key-storage-with-tpm.rst +++ b/doc/source/security/kubernetes/secure-starlingx-rest-and-web-certificates-private-key-storage-with-tpm.rst @@ -31,17 +31,18 @@ re-installed, in order to update the new standby controller's |TPM| device. .. _secure-starlingx-rest-and-web-certificates-private-key-storage-with-tpm-ul-xj3-mqc-d1b: -- Obtain a Root |CA|-signed certificate and key from a trusted Root - |CA|. Refer to the documentation for the external Root |CA| that you - are using, on how to create public certificate and private key pairs, - signed by a Root |CA|, for HTTPS. +- Obtain an intermediate or Root |CA|-signed certificate and key from a + trusted intermediate or Root |CA|. Refer to the documentation for the + external intermediate or Root |CA| that you are using, on how to create + public certificate and private key pairs, signed by an intermediate or + Root-signed |CA|, for HTTPS. .. xbooklink For lab purposes, see :ref:`Locally Creating Certificates - ` for details on how to - create a test Root |CA| certificate and key, and use it to sign test - certificates. + ` for details on how to create + a test intermediate or Root |CA| certificate and key, and use it to sign + test certificates. Put the |PEM| encoded versions of the certificate and key in a single file, and copy the file to the controller host. @@ -88,8 +89,8 @@ re-installed, in order to update the new standby controller's |TPM| device. **** - is the path to the file containing both the Root |CA|-signed - certificate and private key to install. + is the path to the file containing both the intermediate or Root + |CA|-signed certificate and private key to install. .. warning:: For security purposes, the utility deletes the provided SSL private @@ -159,7 +160,7 @@ scenario, you must reinstall the certificate: .. code-block:: none - ~(keystone_admin)$ system certificate-install -m tpm_mode + ~(keystone_admin)]$ system certificate-install -m tpm_mode To disable the use of |TPM| to store the private key of the StarlingX REST @@ -168,5 +169,5 @@ option: .. code-block:: none - ~(keystone_admin)$ system certificate-install + ~(keystone_admin)]$ system certificate-install diff --git a/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst b/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst index 0b6ea2d50..8b8088745 100644 --- a/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst +++ b/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst @@ -6,14 +6,14 @@ Configure Container-backed Remote CLIs and Clients ================================================== -The command line can be accessed from remote computers running Linux, OSX, -and Windows. +The |prod| command lines can be accessed from remote computers running Linux, +MacOS, and Windows. .. rubric:: |context| -This functionality is made available using a docker image for connecting to -the |prod| remotely. This docker image is pulled as required by -configuration scripts. +This functionality is made available using a docker container with +pre-installed CLIs and clients. The container's image is pulled as required by +the remote CLI/client configuration scripts. .. rubric:: |prereq| @@ -22,6 +22,21 @@ more information on installing Docker, see `https://docs.docker.com/install/ `__. For Windows remote clients, Docker is only supported on Windows 10. +.. note:: + You must be able to run docker commands using one of the following options: + + .. _security-configure-container-backed-remote-clis-and-clients-d70e42: + + - Running the scripts using sudo + + - Adding the Linux user to the docker group + + + For more information, see, + `https://docs.docker.com/engine/install/linux-postinstall/ + `__ + + For Windows remote clients, you must run the following commands from a Cygwin terminal. See `https://www.cygwin.com/ `__ for more information about the Cygwin project. @@ -33,23 +48,31 @@ Download the latest release tarball for Cygwin from tarball, extract it to any location and change the Windows variable to include its bin folder from the extracted winpty folder. -The following procedure shows how to configure the Container-backed Remote -CLIs and Clients for an admin user with cluster-admin clusterrole. If using -a non-admin user such as one with role privileges only within a private -namespace, additional configuration is required in order to use -:command:`helm`. +The following procedure shows how to configure the Container-backed Remote CLIs +and Clients for an admin user with cluster-admin clusterrole. If using a +non-admin user such as one with privileges only within a private namespace, +additional configuration is required in order to use :command:`helm`. .. rubric:: |proc| -.. _security-configure-container-backed-remote-clis-and-clients-d70e74: +.. _security-configure-container-backed-remote-clis-and-clients-d70e93: #. On the Controller, configure a Kubernetes service account for user on the remote client. You must configure a Kubernetes service account on the target system and generate a configuration file based on that service account. - Run the following commands logged in as **root** on the local console of the controller. + Run the following commands logged in as **sysadmin** on the local console + of the controller. + + + #. Source the platform environment + + .. code-block:: none + + $ source /etc/platform/openrc + ~(keystone_admin)]$ #. Set environment variables. @@ -60,14 +83,14 @@ namespace, additional configuration is required in order to use .. code-block:: none - % USER="admin-user" - % OUTPUT_FILE="temp-kubeconfig" + ~(keystone_admin)]$ USER="admin-user" + ~(keystone_admin)]$ OUTPUT_FILE="temp-kubeconfig" #. Create an account definition file. .. code-block:: none - % cat < admin-login.yaml + ~(keystone_admin)]$ cat < admin-login.yaml apiVersion: v1 kind: ServiceAccount metadata: @@ -92,59 +115,54 @@ namespace, additional configuration is required in order to use .. code-block:: none - % kubectl apply -f admin-login.yaml + ~(keystone_admin)]$ kubectl apply -f admin-login.yaml #. Store the token value. .. code-block:: none - % TOKEN_DATA=$(kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep ${USER} | awk '{print $1}') | grep "token:" | awk '{print $2}') + ~(keystone_admin)]$ TOKEN_DATA=$(kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep ${USER} | awk '{print $1}') | grep "token:" | awk '{print $2}') - #. Source the platform environment. - - .. code-block:: none - - % source /etc/platform/openrc - - #. Store the OAM IP address. + #. Store the |OAM| IP address. - 1. .. code-block:: none + #. .. code-block:: none - % OAM_IP=$(system oam-show |grep oam_floating_ip| awk '{print $4}') + ~(keystone_admin)]$ OAM_IP=$(system oam-show |grep oam_floating_ip| awk '{print $4}') - 2. AIO-SX uses instead of . The + #. AIO-SX uses instead of . The following shell code ensures that is assigned the correct IP address. .. code-block:: none - % if [ -z "$OAM_IP" ]; then + ~(keystone_admin)]$ if [ -z "$OAM_IP" ]; then OAM_IP=$(system oam-show |grep oam_ip| awk '{print $4}') fi - 3. IPv6 addresses must be enclosed in square brackets. The following shell code does this for you. + #. IPv6 addresses must be enclosed in square brackets. The following + shell code does this for you. .. code-block:: none - % if [[ $OAM_IP =~ .*:.* ]]; then + ~(keystone_admin)]$ if [[ $OAM_IP =~ .*:.* ]]; then OAM_IP="[${OAM_IP}]" fi - #. Generate the temp-kubeconfig file. + #. Generate the admin-kubeconfig file. .. code-block:: none - % sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-cluster wrcp-cluster --server=https://${OAM_IP}:6443 --insecure-skip-tls-verify - % sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-credentials ${USER} --token=$TOKEN_DATA - % sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-context ${USER}@wrcp-cluster --cluster=wrcp-cluster --user ${USER} --namespace=default - % sudo kubectl config --kubeconfig ${OUTPUT_FILE} use-context ${USER}@wrcp-cluster + ~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-cluster wrcp-cluster --server=https://${OAM_IP}:6443 --insecure-skip-tls-verify + ~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-credentials ${USER} --token=$TOKEN_DATA + ~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-context ${USER}@wrcp-cluster --cluster=wrcp-cluster --user ${USER} --namespace=default + ~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} use-context ${USER}@wrcp-cluster -#. On the remote client, install the remote client tarball file from the - StarlingX CENGEN build servers.. +#. Copy the remote client tarball file from the |prod| build servers + to the remote workstation, and extract its content. - The tarball is available from the |prod| area on the StarlingX CENGEN build servers. @@ -152,187 +170,162 @@ namespace, additional configuration is required in order to use - You can extract the tarball's contents anywhere on your client system. - While it is not strictly required to extract the tarball before other - steps, subsequent steps in this example copy files to the extracted - directories as a convenience when running configuration scripts. + .. parsed-literal:: -#. Download the openrc file from the Horizon Web interface to the remote client. + $ cd $HOME + $ tar xvf |prefix|-remote-clients-.tgz + +#. Download the user/tenant openrc file from the Horizon Web interface to the + remote workstation. #. Log in to Horizon as the user and tenant that you want to configure remote access for. + + In this example, the 'admin' user in the 'admin' tenant. #. Navigate to **Project** \> **API Access** \> **Download Openstack RC file**. #. Select **Openstack RC file**. + + The file admin-openrc.sh downloads. -#. Copy the temp-kubeconfig file to the remote workstation. +#. Copy the admin-kubeconfig file to the remote workstation. You can copy the file to any location on the remote workstation. For convenience, this example assumes that it is copied to the location of the extracted tarball. .. note:: - Ensure the temp-kubeconfig file has 666 permissions after copying + Ensure that the admin-kubeconfig file has 666 permissions after copying the file to the remote workstation, otherwise, use the following command to change permissions, :command:`chmod 666 temp\_kubeconfig`. -#. On the remote client, configure the client access. +#. On the remote workstation, configure remote CLI/client access. + This step will also generate a remote CLI/client RC file. #. Change to the location of the extracted tarball. + + .. parsed-literal:: - #. Run the :command:`configure\_client.sh` script to generate a client access file for the platform. + $ cd $HOME/|prefix|-remote-clients-/ - .. note:: - For remote CLI commands that require local filesystem access, - you can specify a working directory when running - :command:`configure\_client.sh` using the -w option. If no - directory is specified, the location from which the - :command:`configure\_client.sh` was run is used for local file - access by remote cli commands. This working directory is - mounted at /wd in the docker container. If remote CLI commands - need access to local files, copy the files to your configured - work directory and then provide the command with the path to - the mounted folder inside the container. + #. Create a working directory that will be mounted by the container + implementing the remote |CLIs|. + + See the description of the :command:`configure\_client.sh` -w option + :ref:`below + ` + for more details. .. code-block:: none - $ mkdir -p $HOME/remote_wd - $ ./configure_client.sh -t platform -r admin_openrc.sh -k temp-kubeconfig \ - -w HOME/remote_wd - $ cd $HOME/remote_wd + $ mkdir -p $HOME/remote_cli_wd + - By default, configure\_client.sh will use container images from - docker.io for both platform clients and openstack clients. You can - optionally use the -p and -a options to override the default docker - with one or two others from a custom registry. For example, to use - the container images from the WRS AWS ECR + #. Run the :command:`configure\_client.sh` script. .. code-block:: none $ ./configure_client.sh -t platform -r admin_openrc.sh -k - temp-kubeconfig -w HOME/remote_wd -p - 625619392498.dkr.ecr.us-west-2.amazonaws.com/starlingx/stx-platfo - rmclients:stx.4.0-v1.3.0 -a - 625619392498.dkr.ecr.us-west-2.amazonaws.com/starlingx/stx-openst - ackclients:master-centos-stable-latest + admin-kubeconfig -w HOME/remote_cli_wd -p + 625619392498.dkr.ecr.us-west-2.amazonaws.com/docker.io/starlingx/stx-platfo + rmclients:stx.4.0-v1.3.0 - If you are working with repositories that require authentication, - you must first perform a :command:`docker login` to that repository - before using remote clients. + If you specify repositories that require authentication, as shown + above, you must first remember to perform a :command:`docker login` to + that repository before using remote |CLIs| for the first time. - A remote\_client\_platform.sh file is generated for use accessing the platform CLI. + The options for configure\_client.sh are: + **-t** + The type of client configuration. The options are platform \(for + |prod-long| |CLI| and clients\) and openstack \(for |prod-os| application + |CLI| and clients\). -#. Test workstation access to the remote platform CLI. + The default value is platform. - Enter your platform password when prompted. + **-r** + The user/tenant RC file to use for :command:`openstack` CLI commands. - .. note:: - The first usage of a command will be slow as it requires that the - docker image supporting the remote clients be pulled from the - remote registry. + The default value is admin-openrc.sh. - .. code-block:: none + **-k** + The kubernetes configuration file to use for :command:`kubectl` and :command:`helm` CLI commands. - root@myclient:/home/user/remote_wd# source remote_client_platform.sh - Please enter your OpenStack Password for project admin as user admin: - root@myclient:/home/user/remote_wd# system host-list - +----+--------------+-------------+----------------+-------------+--------------+ - | id | hostname | personality | administrative | operational | availability | - +----+--------------+-------------+----------------+-------------+--------------+ - | 1 | controller-0 | controller | unlocked | enabled | available | - | 2 | controller-1 | controller | unlocked | enabled | available | - | 3 | compute-0 | worker | unlocked | enabled | available | - | 4 | compute-1 | worker | unlocked | enabled | available | - +----+--------------+-------------+----------------+-------------+--------------+ - root@myclient:/home/user/remote_wd# kubectl -n kube-system get pods - NAME READY STATUS RESTARTS AGE - calico-kube-controllers-767467f9cf-wtvmr 1/1 Running 1 3d2h - calico-node-j544l 1/1 Running 1 3d - calico-node-ngmxt 1/1 Running 1 3d1h - calico-node-qtc99 1/1 Running 1 3d - calico-node-x7btl 1/1 Running 4 3d2h - ceph-pools-audit-1569848400-rrpjq 0/1 Completed 0 12m - ceph-pools-audit-1569848700-jhv5n 0/1 Completed 0 7m26s - ceph-pools-audit-1569849000-cb988 0/1 Completed 0 2m25s - coredns-7cf476b5c8-5x724 1/1 Running 1 3d2h - ... - root@myclient:/home/user/remote_wd# + The default value is temp-kubeconfig. - .. note:: - Some commands used by remote CLI are designed to leave you in a shell prompt, for example: + **-o** + The remote CLI/client RC file generated by this script. + + This RC file needs to be sourced in the shell, to setup required + environment variables and aliases, before running any remote |CLI| + commands. + + For the platform client setup, the default is + remote\_client\_platform.sh. For the openstack application client + setup, the default is remote\_client\_app.sh. + + **-w** + The working directory that will be mounted by the container + implementing the remote |CLIs|. When using the remote |CLIs|, any files + passed as arguments to the remote |CLI| commands need to be in this + directory in order for the container to access the files. The default + value is the directory from which the :command:`configure\_client.sh` + command was run. + + **-p** + Override the container image for the platform |CLI| and clients. + + By default, the platform |CLIs| and clients container image is pulled + from docker.io/starlingx/stx-platformclients. + + For example, to use the container images from the WRS AWS ECR: .. code-block:: none - root@myclient:/home/user/remote_wd# openstack + $ ./configure_client.sh -t platform -r admin-openrc.sh -k + admin-kubeconfig -w $HOME/remote_cli_wd -p + 625619392498.dkr.ecr.us-west-2.amazonaws.com/docker.io/starlingx/stx-platformclients:stx.4.0-v1.3.0-wrs.1 + + - or + If you specify repositories that require authentication, you must first + perform a :command:`docker login` to that repository before using + remote |CLIs|. - .. code-block:: none + **-a** + Override the OpenStack application image. - root@myclient:/home/user/remote_wd# kubectl exec -ti -- /bin/bash + By default, the OpenStack |CLIs| and clients container image is pulled + from docker.io/starlingx/stx-openstackclients. - In some cases the mechanism for identifying commands that should - leave you at a shell prompt does not identify them correctly. If - you encounter such scenarios, you can force-enable or disable the - shell options using the or - variables before the command. + The :command:`configure-client.sh` command will generate a remote\_client\_platform.sh RC file. This RC file needs to be sourced in the shell to set up required environment variables and aliases before any remote CLI commands can be run. - For example: +#. Copy the file remote\_client\_platform.sh to $HOME/remote\_cli\_wd - .. code-block:: none +.. rubric:: |postreq| - root@myclient:/home/user/remote_wd# FORCE_SHELL=true kubectl exec -ti -- /bin/bash - root@myclient:/home/user/remote_wd# FORCE_NO_SHELL=true kubectl exec -- ls +After configuring the platform's container-backed remote CLIs/clients, the +remote platform CLIs can be used in any shell after sourcing the generated +remote CLI/client RC file. This RC file sets up the required environment +variables and aliases for the remote |CLI| commands. - You cannot use both variables at the same time. - -#. If you need to run a remote CLI command that references a local file, - then that file must be copied to or created in the working directory - specified on the ./config\_client.sh command and referenced as under /wd/ - in the actual command. - - For example: - - .. code-block:: none - - root@myclient:/home/user# cd $HOME/remote_wd - root@myclient:/home/user/remote_wd# kubectl -n kube-system create -f test/test.yml - pod/test-pod created - root@myclient:/home/user/remote_wd# kubectl -n kube-system delete -f test/test.yml - pod/test-pod deleted - -#. Do the following to use helm. - - .. note:: - For non-admin users, additional configuration is required first as - discussed in *Configure Remote Helm Client for Non-Admin Users*. - - .. note:: - When using helm, any command that requires access to a helm - repository \(managed locally\) will require that you be in the - $HOME/remote\_wd directory and use the --home ./helm option. - - - #. Do the initial setup of the helm client. - - .. code-block:: none - - % helm init --client-only --home "./.helm" - - #. Run a helm command. - - .. code-block:: none - - $ helm list - $ helm install --name wordpress stable/wordpress --home "./helm" +.. note:: + Consider adding this command to your .login or shell rc file, such + that your shells will automatically be initialized with the environment + variables and aliases for the remote |CLI| commands. +See :ref:`Using Container-backed Remote CLIs and Clients ` for details. +**Related information** .. seealso:: + :ref:`Using Container-backed Remote CLIs and Clients + ` + :ref:`Install Kubectl and Helm Clients Directly on a Host ` diff --git a/doc/source/security/kubernetes/security-default-firewall-rules.rst b/doc/source/security/kubernetes/security-default-firewall-rules.rst index 2ec4d468f..019de2ede 100644 --- a/doc/source/security/kubernetes/security-default-firewall-rules.rst +++ b/doc/source/security/kubernetes/security-default-firewall-rules.rst @@ -16,7 +16,7 @@ You can view the configured firewall rules with the following command: .. code-block:: none - ~(keystone_admin)$ kubectl describe globalnetworkpolicy + ~(keystone_admin)]$ kubectl describe globalnetworkpolicy Name: controller-oam-if-gnp Namespace: Labels: @@ -85,7 +85,7 @@ You can view the configured firewall rules with the following command: Where: -.. _security-default-firewall-rules-d477e47: +.. _security-default-firewall-rules-d488e47: .. table:: diff --git a/doc/source/security/kubernetes/security-firewall-options.rst b/doc/source/security/kubernetes/security-firewall-options.rst index e20e58f16..692ff20c4 100644 --- a/doc/source/security/kubernetes/security-firewall-options.rst +++ b/doc/source/security/kubernetes/security-firewall-options.rst @@ -6,25 +6,25 @@ Firewall Options ================ -|prod| incorporates a default firewall for the OAM network. You can configure +|prod| incorporates a default firewall for the |OAM| network. You can configure additional Kubernetes Network Policies in order to augment or override the default rules. The |prod| firewall uses the Kubernetes Network Policies \(using the Calico -CNI\) to implement a firewall on the OAM network. +|CNI|\) to implement a firewall on the |OAM| network. A minimal set of rules is always applied before any custom rules, as follows: -.. _security-firewall-options-d628e35: +.. _security-firewall-options-ul-xw2-qkw-g3b: -- Non-OAM traffic is always accepted. +- Non-|OAM| traffic is always accepted. - Egress traffic is always accepted. - |SM| traffic is always accepted. -- SSH traffic is always accepted. +- |SSH| traffic is always accepted. You can introduce custom rules by creating and installing custom Kubernetes diff --git a/doc/source/security/kubernetes/security-hardening-firewall-options.rst b/doc/source/security/kubernetes/security-hardening-firewall-options.rst index 8d673adbb..93b6ac8f9 100644 --- a/doc/source/security/kubernetes/security-hardening-firewall-options.rst +++ b/doc/source/security/kubernetes/security-hardening-firewall-options.rst @@ -18,13 +18,13 @@ A minimal set of rules is always applied before any custom rules, as follows: .. _firewall-options-ul-gjq-k1g-mmb: -- Non-OAM traffic is always accepted. +- Non-|OAM| traffic is always accepted. - Egress traffic is always accepted. - |SM| traffic is always accepted. -- SSH traffic is always accepted. +- |SSH| traffic is always accepted. .. note:: It is recommended to disable port 80 when HTTPS is enabled for external @@ -35,7 +35,7 @@ Operational complexity: .. _firewall-options-ul-hjq-k1g-mmb: -- |prod| provides OAM firewall rules through Kubernetes Network Policies. +- |prod| provides |OAM| firewall rules through Kubernetes Network Policies. For more information, see :ref:`Firewall Options `. @@ -47,9 +47,9 @@ Operational complexity: Default Firewall Rules ---------------------- -|prod| applies these default firewall rules on the OAM network. The default +|prod| applies these default firewall rules on the |OAM| network. The default rules are recommended for most applications. -For a complete listing, see :ref:`Default Firewall Rules +For a complete listings, see :ref:`Default Firewall Rules `. diff --git a/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst b/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst index e214f65e0..3f5eeaf6f 100644 --- a/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst +++ b/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst @@ -141,6 +141,9 @@ configuration is required in order to use :command:`helm`. :ref:`Configure Container-backed Remote CLIs and Clients ` + :ref:`Using Container-backed Remote CLIs and Clients + ` + :ref:`Configure Remote Helm Client for Non-Admin Users ` diff --git a/doc/source/security/kubernetes/security-install-update-the-docker-registry-certificate.rst b/doc/source/security/kubernetes/security-install-update-the-docker-registry-certificate.rst index 77ac5e737..7f545b28c 100644 --- a/doc/source/security/kubernetes/security-install-update-the-docker-registry-certificate.rst +++ b/doc/source/security/kubernetes/security-install-update-the-docker-registry-certificate.rst @@ -10,42 +10,42 @@ The local docker registry provides secure HTTPS access using the registry API. .. rubric:: |context| -By default a self-signed certificate is generated at installation time for -the registry API. For more secure access, a Root |CA|-signed certificate is -strongly recommended. +By default a self-signed certificate is generated at installation time for the +registry API. For more secure access, an intermediate or Root |CA|-signed +certificate is strongly recommended. -The Root |CA|-signed certificate for the registry must have at least the -following |SANs|: DNS:registry.local, DNS:registry.central, IP -Address:, IP Address:. -Use the :command:`system addrpool-list` command to get the |OAM| floating IP +The intermediate or Root |CA|-signed certificate for the registry must have at +least the following |SANs|: DNS:registry.local, DNS:registry.central, IP +Address:, IP Address:. Use +the :command:`system addrpool-list` command to get the |OAM| floating IP Address and management floating IP Address for your system. You can add any additional DNS entry\(s\) that you have set up for your |OAM| floating IP Address. -Use the following procedure to install a Root |CA|-signed certificate to either -replace the default self-signed certificate or to replace an expired or soon -to expire certificate. +Use the following procedure to install an intermediate or Root |CA|-signed +certificate to either replace the default self-signed certificate or to replace +an expired or soon to expire certificate. .. rubric:: |prereq| -Obtain a Root |CA|-signed certificate and key from a trusted Root |CA|. Refer -to the documentation for the external Root |CA| that you are using, on how to -create public certificate and private key pairs, signed by a Root |CA|, for -HTTPS. +Obtain an intermediate or Root |CA|-signed certificate and key from a trusted +intermediate or Root |CA|. Refer to the documentation for the external Root +|CA| that you are using, on how to create public certificate and private key +pairs, signed by an intermediate or Root |CA|, for HTTPS. -For lab purposes, see Appendix A for how to create a test Root |CA| -certificate and key, and use it to sign test certificates. +For lab purposes, see Appendix A for how to create a test intermediate or Root +|CA| certificate and key, and use it to sign test certificates. Put the |PEM| encoded versions of the certificate and key in a single file, and copy the file to the controller host. -Also, obtain the certificate of the Root |CA| that signed the above -certificate. +Also, obtain the certificate of the intermediate or Root |CA| that signed the +above certificate. .. rubric:: |proc| -.. _security-install-update-the-docker-registry-certificate-d516e68: +.. _security-install-update-the-docker-registry-certificate-d527e71: #. In order to enable internal use of the docker registry certificate, update the trusted |CA| list for this system with the Root |CA| associated @@ -53,14 +53,15 @@ certificate. .. code-block:: none - ~(keystone_admin)$ system certificate-install --mode ssl_ca + ~(keystone_admin)]$ system certificate-install --mode ssl_ca where: **** - is the path to the Root |CA| certificate associated with the docker - registry Root |CA|-signed certificate. + is the path to the intermediate or Root |CA| certificate associated + with the docker registry's intermediate or Root |CA|-signed + certificate. #. Update the docker registry certificate using the :command:`certificate-install` command. @@ -69,13 +70,13 @@ certificate. .. code-block:: none - ~(keystone_admin)$ system certificate-install --mode docker_registry + ~(keystone_admin)]$ system certificate-install --mode docker_registry where: **** - is the path to the file containing both the docker registry - certificate and private key to install. + is the path to the file containing both the docker registry's + intermediate or Root CA-signed certificate and private key to install. diff --git a/doc/source/security/kubernetes/starlingx-openstack-kubernetes-from-stsadmin-account-login.rst b/doc/source/security/kubernetes/starlingx-openstack-kubernetes-from-stsadmin-account-login.rst new file mode 100644 index 000000000..80d75c2b9 --- /dev/null +++ b/doc/source/security/kubernetes/starlingx-openstack-kubernetes-from-stsadmin-account-login.rst @@ -0,0 +1,21 @@ + +.. fqa1607640080245 +.. _starlingx-openstack-kubernetes-from-stsadmin-account-login: + +============================================================================================= +For StarlingX, Platform OpenStack and Kubernetes CLIs from the 'sysadmin' Linux Account Login +============================================================================================= + +You can establish credentials for StarlingX, Platform OpenStack and Kubernetes +|CLIs| from the 'sysadmin' Linux account login. + +.. rubric:: |context| + +For the 'sysadmin' account, you can acquire both Keystone admin credentials for +StarlingX and Platform |CLIs|, and Kubernetes admin credentials for Kubernetes +|CLIs| by executing the following command: + +.. code-block:: none + + user1@controller-0:~$ source /etc/platform/openrc + diff --git a/doc/source/security/kubernetes/starlingx-rest-api-applications-and-the-web-administration-server.rst b/doc/source/security/kubernetes/starlingx-rest-api-applications-and-the-web-administration-server.rst index 5a689dd9c..d3d8da977 100644 --- a/doc/source/security/kubernetes/starlingx-rest-api-applications-and-the-web-administration-server.rst +++ b/doc/source/security/kubernetes/starlingx-rest-api-applications-and-the-web-administration-server.rst @@ -13,25 +13,19 @@ StarlingX\) and the |prod| web administration server. By default HTTPS access to StarlingX REST and Web Server's endpoints are disabled; i.e. accessible via HTTP only. -For secure HTTPS access, an x509 certificate and key is required. +For secure HTTPS access, an x509 certificate and key is required. When HTTPS is +enabled for the first time on a |prod| system, a self-signed certificate and +key are automatically generated and installed for the StarlingX REST and Web +Server endpoints. .. note:: - The default HTTPS X.509 certificates that are used by |prod-long| for - authentication are not signed by a known authority. For increased - security, obtain, install, and use certificates that have been signed - by a Root certificate authority. Refer to the documentation for the - external Root |CA| that you are using, on how to create public - certificate and private key pairs, signed by a Root |CA|, for HTTPS. + Refer to the documentation for the external Intermediate or Root |CA| that + you are using, on how to create public certificate and private key pairs, + signed by an Intermediate or Root |CA|, for HTTPS. -By default a self-signed certificate and key is generated and installed by -|prod| for the StarlingX REST and Web Server endpoints for evaluation -purposes. This certificate and key is installed by default when HTTPS -access is first enabled for these services. In order to connect, remote -clients must be configured to accept the self-signed certificate without -verifying it \("insecure" mode\). - -For secure remote access, a Root |CA|-signed certificate and key are -required. The use of a Root |CA|-signed certificate is strongly recommended. +For secure remote access, an intermediate or Root |CA|-signed certificate and +key are required. The use of a Root |CA|-signed certificate is strongly +recommended. You can update the certificate used for HTTPS access at any time. diff --git a/doc/source/security/kubernetes/starlingx-system-accounts-system-account-password-rules.rst b/doc/source/security/kubernetes/starlingx-system-accounts-system-account-password-rules.rst index 11ef529c7..b32d3f736 100644 --- a/doc/source/security/kubernetes/starlingx-system-accounts-system-account-password-rules.rst +++ b/doc/source/security/kubernetes/starlingx-system-accounts-system-account-password-rules.rst @@ -12,7 +12,7 @@ The following rules apply to all System Accounts \(Local LDAP, sysadmin, other Linux Accounts, and Keystone accounts\): -.. _starlingx-system-accounts-system-account-password-rules-ul-jwb-g15-zw: +.. _starlingx-system-accounts-system-account-password-rules-ul-evs-dsn-ynb: - The password must be at least seven characters long. @@ -34,6 +34,8 @@ other Linux Accounts, and Keystone accounts\): The following additional rules apply to Local Linux accounts only \(Local LDAP, sysadmin, and other Linux accounts\): +.. _starlingx-system-accounts-system-account-password-rules-ul-rvj-jsn-ynb: + - Dictionary words or simple number sequences \(for example, 123 or 321\) are not allowed diff --git a/doc/source/security/kubernetes/the-sysadmin-account.rst b/doc/source/security/kubernetes/the-sysadmin-account.rst index 01081d871..c06201e75 100644 --- a/doc/source/security/kubernetes/the-sysadmin-account.rst +++ b/doc/source/security/kubernetes/the-sysadmin-account.rst @@ -9,7 +9,7 @@ The sysadmin Account This is a local, per-host, sudo-enabled account created automatically when a new host is provisioned. -This Linux user account is used by the system administrator as it has +This Linux user account is used by the primary system administrator as it has extended privileges. On controller nodes, this account is available even before :command:`ansible diff --git a/doc/source/security/kubernetes/types-of-system-accounts.rst b/doc/source/security/kubernetes/types-of-system-accounts.rst new file mode 100644 index 000000000..6cbb2ef0e --- /dev/null +++ b/doc/source/security/kubernetes/types-of-system-accounts.rst @@ -0,0 +1,25 @@ + +.. ihc1607982648629 +.. _types-of-system-accounts: + +======================== +Types of System Accounts +======================== + +This Chapter describes the system accounts available in a |prod| +system. + +For more information, see: + +.. _types-of-system-accounts-ul-rms-mwk-znb: + +- :ref:`Linux User Accounts ` + +- :ref:`Kubernetes Service Accounts ` + +- :ref:`Keystone Accounts ` + +- :ref:`Remote Windows Active Directory Accounts ` + +- :ref:`Linux User Accounts ` + diff --git a/doc/source/security/kubernetes/uefi-secure-boot.rst b/doc/source/security/kubernetes/uefi-secure-boot.rst index 8fc374281..e056f729b 100644 --- a/doc/source/security/kubernetes/uefi-secure-boot.rst +++ b/doc/source/security/kubernetes/uefi-secure-boot.rst @@ -27,6 +27,6 @@ Operational complexity: - This must be done for each node before starting the installation. -For more information, see :ref:`UEFI Secure Boot +For more information, see the section :ref:`UEFI Secure Boot `. diff --git a/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst b/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst new file mode 100644 index 000000000..35fdb938e --- /dev/null +++ b/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst @@ -0,0 +1,158 @@ + +.. sso1605707703320 +.. _using-container-backed-remote-clis-and-clients: + +============================================ +Use Container-backed Remote CLIs and Clients +============================================ + +Remote platform |CLIs| can be used in any shell after sourcing the generated +remote CLI/client RC file. This RC file sets up the required environment +variables and aliases for the remote |CLI| commands. + +.. rubric:: |prereq| + +.. _using-container-backed-remote-clis-and-clients-ul-vcd-4rf-14b: + +- Consider adding the following command to your .login or shell rc file, such + that your shells will automatically be initialized with the environment + variables and aliases for the remote |CLI| commands. Otherwise, execute it + before proceeding: + + .. code-block:: none + + root@myclient:/home/user/remote_cli_wd# source remote_client_platform.sh + +- You must have completed the configuration steps described in + :ref:`Configuring Container-backed Remote CLIs and Clients + ` + before proceeding. + +- If you specified repositories that require authentication when configuring + the container-backed remote |CLIs|, you must perform a :command:`docker + login` to that repository before using remote |CLIs| for the first time + +.. rubric:: |proc| + +- For simple StarlingX :command:`system` |CLI| and Kubernetes + :command:`kubectl` |CLI| commands: + + .. note:: + The first usage of a remote |CLI| command will be slow as it requires + that the docker image supporting the remote CLIs/clients be pulled from + the remote registry. + + .. code-block:: none + + Please enter your OpenStack Password for project admin as user admin: + root@myclient:/home/user/remote_cli_wd# system host-list + +----+--------------+-------------+----------------+-------------+--------------+ + | id | hostname | personality | administrative | operational | availability | + +----+--------------+-------------+----------------+-------------+--------------+ + | 1 | controller-0 | controller | unlocked | enabled | available | + | 2 | controller-1 | controller | unlocked | enabled | available | + | 3 | compute-0 | worker | unlocked | enabled | available | + | 4 | compute-1 | worker | unlocked | enabled | available | + +----+--------------+-------------+----------------+-------------+--------------+ + root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system get pods + NAME READY STATUS RESTARTS AGE + calico-kube-controllers-767467f9cf-wtvmr 1/1 Running 1 3d2h + calico-node-j544l 1/1 Running 1 3d + calico-node-ngmxt 1/1 Running 1 3d1h + calico-node-qtc99 1/1 Running 1 3d + calico-node-x7btl 1/1 Running 4 3d2h + ceph-pools-audit-1569848400-rrpjq 0/1 Completed 0 12m + ceph-pools-audit-1569848700-jhv5n 0/1 Completed 0 7m26s + ceph-pools-audit-1569849000-cb988 0/1 Completed 0 2m25s + coredns-7cf476b5c8-5x724 1/1 Running 1 3d2h + ... + root@myclient:/home/user/remote_cli_wd# + + .. note:: + Some |CLI| commands are designed to leave you in a shell prompt, for example: + + .. code-block:: none + + root@myclient:/home/user/remote_cli_wd# openstack + + or + + .. code-block:: none + + root@myclient:/home/user/remote_cli_wd# kubectl exec -ti -- /bin/bash + + In most cases, the remote |CLI| will detect and handle these commands + correctly. If you encounter cases that are not handled correctly, you + can force-enable or disable the shell options using the + or variables before the command. + + For example: + + .. code-block:: none + + root@myclient:/home/user/remote_cli_wd# FORCE_SHELL=true kubectl exec -ti -- /bin/bash + root@myclient:/home/user/remote_cli_wd# FORCE_NO_SHELL=true kubectl exec -- ls + + You cannot use both variables at the same time. + +- If you need to run a remote |CLI| command that references a local file, + then that file must be copied to or created in the working directory + specified in the -w option on the ./config\_client.sh command. + + For example: + + .. code-block:: none + + root@myclient:/home/user# cp //test.yml $HOME/remote_cli_wd/test.yml + root@myclient:/home/user# cd $HOME/remote_cli_wd + root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system create -f test.yml + pod/test-pod created + root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system delete -f test.yml + pod/test-pod deleted + +- Do the following to use helm. + + .. note:: + For non-admin users, additional configuration is required first as + discussed in :ref:`Configuring Remote Helm Client for Non-Admin Users + `. + + .. note:: + When using helm, any command that requires access to a helm repository + \(managed locally\) will require that you be in the + $HOME/remote\_cli\_wd directory and use the --home ./.helm option. + + + #. Do the initial setup of the helm client. + + .. note:: + This command assumes you are using Helm v2. + + .. code-block:: none + + % cd $HOME/remote_cli_wd + % helm init --client-only --home "./.helm" + + #. Run a helm command. + + .. code-block:: none + + % cd $HOME/remote_cli_wd + % helm list + % helm install --name wordpress stable/wordpress --home "./.helm" + + + +**Related information** + +.. seealso:: + + :ref:`Configuring Container-backed Remote CLIs and Clients + ` + + :ref:`Installing Kubectl and Helm Clients Directly on a Host + ` + + :ref:`Configuring Remote Helm Client for Non-Admin Users + ` + diff --git a/doc/source/security/kubernetes/web-administration-login-timeout.rst b/doc/source/security/kubernetes/web-administration-login-timeout.rst index ae85448c6..7f23ece92 100644 --- a/doc/source/security/kubernetes/web-administration-login-timeout.rst +++ b/doc/source/security/kubernetes/web-administration-login-timeout.rst @@ -12,6 +12,6 @@ out after 50 minutes \(the Keystone Token Expiry time\), regardless of activity. Operational complexity: No additional configuration is required. You can also block user access after a set number of failed login attempts as -described in :ref:`Configure Horizon User Lockout on Failed Logins +described in see :ref:`Configure Horizon User Lockout on Failed Logins `. diff --git a/doc/source/shared/abbrevs.txt b/doc/source/shared/abbrevs.txt index 4609cc096..6802bc0a2 100755 --- a/doc/source/shared/abbrevs.txt +++ b/doc/source/shared/abbrevs.txt @@ -133,4 +133,4 @@ .. |VXLAN| replace:: :abbr:`VXLAN (Virtual eXtensible Local Area Network)` .. |VXLANs| replace:: :abbr:`VXLANs (Virtual eXtensible Local Area Networks)` .. |XML| replace:: :abbr:`XML (eXtensible Markup Language)` -.. |YAML| replace:: :abbr:`YAML (YAML Ain't Markup Language)` \ No newline at end of file +.. |YAML| replace:: :abbr:`YAML (YAML Ain't Markup Language)` diff --git a/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-installing-kubectl-and-helm-clients-directly-on-a-host.rst b/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-installing-kubectl-and-helm-clients-directly-on-a-host.rst index cb90fc331..2351b3f5f 100644 --- a/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-installing-kubectl-and-helm-clients-directly-on-a-host.rst +++ b/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-installing-kubectl-and-helm-clients-directly-on-a-host.rst @@ -58,7 +58,7 @@ You will need the following information from your |prod| administrator: % sudo apt-get update % sudo apt-get install -y kubectl - .. _security-installing-kubectl-and-helm-clients-directly-on-a-host-local-configuration-context: + .. _security-install-kubectl-and-helm-clients-directly-on-a-host-local-configuration-context: #. Set up the local configuration and context. diff --git a/doc/source/usertasks/kubernetes/usertask-using-container-backed-remote-clis-and-clients.rst b/doc/source/usertasks/kubernetes/usertask-using-container-backed-remote-clis-and-clients.rst index 55cc82694..9c6193ac0 100644 --- a/doc/source/usertasks/kubernetes/usertask-using-container-backed-remote-clis-and-clients.rst +++ b/doc/source/usertasks/kubernetes/usertask-using-container-backed-remote-clis-and-clients.rst @@ -118,10 +118,10 @@ Helm Do the following to use helm. -.. xreflink .. note:: - For non-admin users, additional configuration is required first as - discussed in |sec-doc|: :ref:`Configuring Remote Helm Client for - Non-Admin Users `. +.. note:: + For non-admin users, additional configuration is required first as + discussed in |sec-doc|: :ref:`Configuring Remote Helm Client for + Non-Admin Users `. .. note:: When using helm, any command that requires access to a helm repository