starlingx/docs
Code Issues Proposed changes

Update Security

Browse Source 
Fixed merge conflict (RS)

Signed-off-by: Rafael Jardim <rafaeljordao.jardim@windriver.com>
Change-Id: I30b882a14196525f440db1108a56bbf862dfaf55
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
This commit is contained in:
Rafael Jardim
2021-03-15 16:56:04 -03:00
committed by Ron Stone
parent f9d1b4905d
commit d95c80d36f
59 changed files with 944 additions and 668 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/source/security/kubernetes/add-a-trusted-ca.rst
View File

@@ -39,7 +39,7 @@ For example:
.. code-block:: none .. code-block:: none
apiserver_cert_sans: <trusted-ca-bundle-pem-file> ssl_ca_cert: /path/to/ssl_ca_cert_file
The *ssl\_ca\_cert* value is the absolute path of the file containing the 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 |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 .. code-block:: none
~(keystone_admin)$ system certificate-install -m ssl_ca <trusted-ca-bundle-pem-file> ~(keystone_admin)]$ system certificate-install -m ssl_ca <trusted-ca-bundle-pem-file>
For example: For example:
.. code-block:: none .. 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, WARNING: For security reasons, the original certificate,
containing the private key, will be removed, containing the private key, will be removed,
once the private key is processed. once the private key is processed.
@@ -100,7 +100,7 @@ running the following command:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-list ~(keystone_admin)]$ system certificate-list
where, all entries with certtype = ssl\_ca are trusted |CA| certificates. where, all entries with certtype = ssl\_ca are trusted |CA| certificates.
@@ -109,7 +109,7 @@ running the following command:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-uninstall -m ssl_ca <UUID> ~(keystone_admin)]$ system certificate-uninstall -m ssl_ca <UUID>
where, <UUID> is the UUID of the ssl\_ca certtype to be removed. where, <UUID> is the UUID of the ssl\_ca certtype to be removed.

3
doc/source/security/kubernetes/authentication-of-software-delivery.rst
View File

@@ -23,3 +23,6 @@ This is done for:
Both software patches and loads are cryptographically signed as part of Both software patches and loads are cryptographically signed as part of
|org| builds and are authenticated before they are loaded on a system via |org| builds and are authenticated before they are loaded on a system via
|prod| REST APIs, CLIs or GUI. |prod| REST APIs, CLIs or GUI.
.. xbooklink For more information on patches, see |updates-doc|: :ref:`Software Updates
<software-updates-and-upgrades-software-updates>`.

6
doc/source/security/kubernetes/configure-horizon-user-lockout-on-failed-logins.rst
View File

@@ -32,7 +32,7 @@ You can change the duration of the lockout using the following CLI command:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-modify horizon auth \ ~(keystone_admin)]$ system service-parameter-modify horizon auth \
lockout_seconds=<duration> lockout_seconds=<duration>
where <duration> is the time in seconds. where <duration> is the time in seconds.
@@ -42,7 +42,7 @@ using the following CLI command:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-modify horizon auth \ ~(keystone_admin)]$ system service-parameter-modify horizon auth \
lockout_retries=<attempts> lockout_retries=<attempts>
where <attempts> is the number of allowed retries. where <attempts> is the number of allowed retries.
@@ -51,7 +51,7 @@ For the changes to take effect, you must apply them:
.. code-block:: none .. 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 Allow about 30 seconds after applying the changes for the Web service to
restart. restart.

8
doc/source/security/kubernetes/configure-http-and-https-ports-for-horizon-using-the-cli.rst
View File

@@ -24,7 +24,7 @@ list the configured **HTTP**, and **HTTPS** ports.
.. code-block:: none .. 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| | uuid | service | section | name | value |personality |Resource|
+---------+----------+---------+------------+-------+------------+--------+ +---------+----------+---------+------------+-------+------------+--------+
@@ -39,16 +39,16 @@ list the configured **HTTP**, and **HTTPS** ports.
.. code-block:: none .. 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. #. Apply the service parameter change.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-apply http ~(keystone_admin)]$ system service-parameter-apply http
Applying http service parameters Applying http service parameters
.. note:: .. note::

4
doc/source/security/kubernetes/configure-kubectl-with-a-context-for-the-user.rst
View File

@@ -21,14 +21,14 @@ do so from a remote workstation.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl config set-cluster mywrcpcluster --server=https://<oam-floating-ip>:6443 ~(keystone_admin)]$ kubectl config set-cluster mywrcpcluster --server=https://<oam-floating-ip>:6443
#. Set up a context for **testuser** in this cluster in kubectl. #. Set up a context for **testuser** in this cluster in kubectl.
.. code-block:: none .. 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

4
doc/source/security/kubernetes/configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system.rst
View File

@@ -30,7 +30,7 @@ you can do so at any time using service parameters.
.. code-block:: none .. 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=<client> - oidc\_client\_id=<client>
@@ -67,7 +67,7 @@ you can do so at any time using service parameters.
.. code-block:: none .. 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 For more information on |OIDC| Authentication for subclouds, see
:ref:`Centralized OIDC Authentication Setup for Distributed Cloud :ref:`Centralized OIDC Authentication Setup for Distributed Cloud

20
doc/source/security/kubernetes/configure-local-cli-access.rst
View File

@@ -55,6 +55,18 @@ required system maintenance, administration and troubleshooting tasks.
% echo "export KUBECONFIG=~/.kube/config" >> ~/.profile % echo "export KUBECONFIG=~/.kube/config" >> ~/.profile
% exit % 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 <KUBECONFIG> environment variable is set correctly #. Confirm that the <KUBECONFIG> environment variable is set correctly
and that :command:`kubectl` commands are functioning properly. and that :command:`kubectl` commands are functioning properly.
@@ -80,7 +92,7 @@ For example:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system host-list ~(keystone_admin)]$ system host-list
+----+--------------+-------------+----------------+-------------+--------------+ +----+--------------+-------------+----------------+-------------+--------------+
| id | hostname | personality | administrative | operational | availability | | id | hostname | personality | administrative | operational | availability |
+----+--------------+-------------+----------------+-------------+--------------+ +----+--------------+-------------+----------------+-------------+--------------+
@@ -104,7 +116,7 @@ For example:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ fm alarm-list ~(keystone_admin)]$ fm alarm-list
+-------+---------------+---------------------+----------+---------------+ +-------+---------------+---------------------+----------+---------------+
| Alarm | Reason Text | Entity ID | Severity | Time Stamp | | Alarm | Reason Text | Entity ID | Severity | Time Stamp |
@@ -125,10 +137,10 @@ For example:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl get nodes ~(keystone_admin)]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION NAME STATUS ROLES AGE VERSION
controller-0 Ready master 5d19h v1.13.5 controller-0 Ready master 5d19h v1.13.5
~(keystone_admin)$ kubectl get pods ~(keystone_admin)]$ kubectl get pods
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
dashboard-kubernetes-dashboard-7749d97f95-bzp5w 1/1 Running 0 3d18h dashboard-kubernetes-dashboard-7749d97f95-bzp5w 1/1 Running 0 3d18h

73
doc/source/security/kubernetes/configure-oidc-auth-applications.rst
View File

@@ -82,22 +82,22 @@ and uploaded by default.
.. code-block:: none .. 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 Create the secret **wadcert** with the |CA|'s certificate that signed
the Active Directory's certificate using the following command: the Active Directory's certificate using the following command:
.. code-block:: none .. 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: #. Specify user overrides for **oidc-auth-apps** application, by using the following command:
.. code-block:: none .. 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 The dex-overrides.yaml file contains the desired dex helm chart overrides
\(that is, the LDAP connector configuration for the Active Directory \(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 Directory service login information \(that is, bindDN, and bindPW\), and
example :command:`userSearch`, and :command:`groupSearch` clauses. 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 .. code-block:: none
config: config:
staticClients:
- id: stx-oidc-client-app
name: STX OIDC Client app
redirectURIs: ['<OAM floating IP address>/callback']
secret: BetterSecret
client_secret: BetterSecret
expiry: expiry:
idTokens: "10h" idTokens: "10h"
connectors: connectors:
@@ -134,7 +169,7 @@ and uploaded by default.
insecureNoSSL: false insecureNoSSL: false
insecureSkipVerify: false insecureSkipVerify: false
bindDN: cn=Administrator,cn=Users,dc=cumulus,dc=wrs,dc=com bindDN: cn=Administrator,cn=Users,dc=cumulus,dc=wrs,dc=com
bindPW: Li69nux* bindPW: [<password>]
usernamePrompt: Username usernamePrompt: Username
userSearch: userSearch:
baseDN: ou=Users,ou=Titanium,dc=cumulus,dc=wrs,dc=com baseDN: ou=Users,ou=Titanium,dc=cumulus,dc=wrs,dc=com
@@ -155,7 +190,7 @@ and uploaded by default.
secretName: wadcert secretName: wadcert
extraVolumeMounts: extraVolumeMounts:
- name: certdir - name: certdir
mountPath: /etc/ssl/certs/adcer mountPath: /etc/ssl/certs/adcert
If more than one Windows Active Directory service is required for If more than one Windows Active Directory service is required for
authenticating the different users of the |prod|, multiple '**ldap**' 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 Whenever you use multiple '**ldap**' type connectors, ensure you use
unique '**name:**' and '**id:**' parameters for each connector. 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 #. Use the :command:`system application-apply` command to apply the
configuration: configuration:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system application-apply oidc-auth-apps ~(keystone_admin)]$ system application-apply oidc-auth-apps

3
doc/source/security/kubernetes/configure-remote-cli-access.rst
View File

@@ -36,6 +36,9 @@ either of the above two methods.
:ref:`Configure Container-backed Remote CLIs and Clients :ref:`Configure Container-backed Remote CLIs and Clients
<security-configure-container-backed-remote-clis-and-clients>` <security-configure-container-backed-remote-clis-and-clients>`
:ref:`Using Container-backed Remote CLIs and Clients
<using-container-backed-remote-clis-and-clients>`
:ref:`Install Kubectl and Helm Clients Directly on a Host :ref:`Install Kubectl and Helm Clients Directly on a Host
<security-install-kubectl-and-helm-clients-directly-on-a-host>` <security-install-kubectl-and-helm-clients-directly-on-a-host>`

23
doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst
View File

@@ -26,7 +26,7 @@ remotely.
.. note:: .. note::
If you are using container-backed helm CLIs and clients \(method 1\), 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| .. rubric:: |proc|
@@ -37,7 +37,7 @@ remotely.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ NAMESPACE=default ~(keystone_admin)]$ NAMESPACE=default
#. Set up accounts, roles and bindings. #. Set up accounts, roles and bindings.
@@ -50,7 +50,7 @@ remotely.
.. code-block:: none .. code-block:: none
% cat <<EOF > default-tiller-sa.yaml ~(keystone_admin)]$ cat <<EOF > default-tiller-sa.yaml
apiVersion: v1 apiVersion: v1
kind: ServiceAccount kind: ServiceAccount
metadata: metadata:
@@ -81,16 +81,16 @@ remotely.
name: tiller name: tiller
namespace: default namespace: default
EOF 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. #. Execute the following commands as an admin-level user.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl create clusterrole tiller --verb get ~(keystone_admin)]$ kubectl create clusterrole tiller --verb get
--resource namespaces --resource namespaces
~(keystone_admin)$ kubectl create clusterrolebinding tiller ~(keystone_admin)]$ kubectl create clusterrolebinding tiller
--clusterrole tiller --serviceaccount ${NAMESPACE}:tiller --clusterrole tiller --serviceaccount ${NAMESPACE}:tiller
@@ -98,13 +98,13 @@ remotely.
.. code-block:: none .. 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: --tiller-namespace=$NAMESPACE --output yaml | sed 's@apiVersion:
extensions/v1beta1@apiVersion: apps/v1@' | sed 's@ replicas: 1@ extensions/v1beta1@apiVersion: apps/v1@' | sed 's@ replicas: 1@
replicas: 1\n \ selector: {"matchLabels": {"app": "helm", "name": replicas: 1\n \ selector: {"matchLabels": {"app": "helm", "name":
"tiller"}}@' > helm-init.yaml "tiller"}}@' > helm-init.yaml
~(keystone_admin)$ kubectl apply -f helm-init.yaml ~(keystone_admin)]$ kubectl apply -f helm-init.yaml
~(keystone_admin)$ helm init –client-only ~(keystone_admin)]$ helm init --client-only --home "./.helm"
.. note:: .. note::
Ensure that each of the patterns between single quotes in the above Ensure that each of the patterns between single quotes in the above
@@ -144,7 +144,7 @@ example:
.. note:: .. note::
If you are using container-backed helm CLI and Client \(method 1\), then 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: option on all helm commands:
.. code-block:: none .. code-block:: none
@@ -160,6 +160,9 @@ example:
:ref:`Configure Container-backed Remote CLIs and Clients :ref:`Configure Container-backed Remote CLIs and Clients
<security-configure-container-backed-remote-clis-and-clients>` <security-configure-container-backed-remote-clis-and-clients>`
:ref:`Using Container-backed Remote CLIs and Clients
<using-container-backed-remote-clis-and-clients>`
:ref:`Install Kubectl and Helm Clients Directly on a Host :ref:`Install Kubectl and Helm Clients Directly on a Host
<security-install-kubectl-and-helm-clients-directly-on-a-host>` <security-install-kubectl-and-helm-clients-directly-on-a-host>`

2
doc/source/security/kubernetes/configure-vault.rst
View File

@@ -133,7 +133,7 @@ The following steps use Vault's REST API and is run from controller-0.
.. code-block:: none .. 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":"<password>"}' https://sva-vault.vault.svc.cluster.local:8200/v1/secret/basic-secret/helloworld
#. Verify the secret. #. Verify the secret.

10
doc/source/security/kubernetes/create-an-admin-type-service-account.rst
View File

@@ -23,24 +23,24 @@ an admin service account with cluster-admin role, use the following procedure:
.. code-block:: none .. code-block:: none
% cat <<EOF > joe-admin.yaml % cat <<EOF > admin-user.yaml
apiVersion: v1 apiVersion: v1
kind: ServiceAccount kind: ServiceAccount
metadata: metadata:
name: joe-admin name: admin-user
namespace: kube-system namespace: kube-system
--- ---
apiVersion: rbac.authorization.k8s.io/v1 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding kind: ClusterRoleBinding
metadata: metadata:
name: joe-admin name: admin-user
roleRef: roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
kind: ClusterRole kind: ClusterRole
name: cluster-admin name: cluster-admin
subjects: subjects:
- kind: ServiceAccount - kind: ServiceAccount
name: joe-admin name: admin-user
namespace: kube-system namespace: kube-system
EOF EOF
@@ -48,7 +48,7 @@ an admin service account with cluster-admin role, use the following procedure:
.. code-block:: none .. code-block:: none
% kubectl apply -f joe-admin.yaml % kubectl apply -f admin-user.yaml
.. ..

73
doc/source/security/kubernetes/create-ldap-linux-accounts.rst
View File

@@ -6,24 +6,23 @@
Create LDAP Linux Accounts Create LDAP Linux Accounts
========================== ==========================
|prod| includes a script for creating LDAP Linux accounts with built-in |prod| includes a script for creating |LDAP| Linux accounts.
Keystone user support.
.. rubric:: |context| .. rubric:: |context|
The :command:`ldapusersetup` command provides an interactive method for .. note::
setting up LDAP Linux user accounts with access to StarlingX commands. You For security reasons, it is recommended that ONLY admin level users be
can assign a limited shell or a bash shell. 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 The :command:`ldapusersetup` command provides an interactive method for setting
establish or change Keystone credentials at any time during a session. up |LDAP| Linux user accounts.
Keystone credentials persist for the duration of the session.
Centralized management is implemented using two LDAP servers, one running on Centralized management is implemented using two |LDAP| servers, one running on
each controller node. LDAP server synchronization is automatic using the each controller node. |LDAP| server synchronization is automatic using the
native LDAP content synchronization protocol. 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 commands are installed in the directory /usr/local/sbin, and are available to
any user account in the sudoers list. Included commands are any user account in the sudoers list. Included commands are
:command:`lsldap`, :command:`ldapadduser`, :command:`ldapdeleteuser`, and :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|. 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| .. rubric:: |proc|
#. Log in as **sysadmin**, and start the :command:`ldapusersetup` script. #. 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 .. code-block:: none
Enter username to add to LDAP: 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.
.. code-block:: none .. code-block:: none
Successfully added user user1 to LDAP Successfully added user user1 to |LDAP|
Successfully set password for user user1 Successfully set password for user user1
#. Specify whether to provide a limited shell or a bash shell. #. Specify a secondary user group for this |LDAP| user.
.. 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.
.. code-block:: none .. code-block:: none
@@ -116,7 +79,7 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
.. code-block:: none .. 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 Updating password expiry to 90 days
#. Change the warning period before the password expires. #. Change the warning period before the password expires.
@@ -139,7 +102,7 @@ On completion of the script, the command prompt is displayed.
.. rubric:: |result| .. rubric:: |result|
The LDAP account is created. For information about the user login process, The |LDAP| account is created. For information about the user login process, see
see :ref:`Establish Keystone Credentials from a Linux Account ref:`For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account
<establish-keystone-credentials-from-a-linux-account>`. Login <establish-keystone-credentials-from-a-linux-account>`.

22
doc/source/security/kubernetes/deprovision-windows-active-directory-authentication.rst
View File

@@ -21,44 +21,44 @@ You can remove Windows Active Directory authentication from |prod-long|.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-list ~(keystone_admin)]$ system service-parameter-list
#. Delete each parameter. #. Delete each parameter.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-delete <UUID> ~(keystone_admin)]$ system service-parameter-delete <UUID>
#. Apply the changes. #. Apply the changes.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-apply kubernetes ~(keystone_admin)]$ system service-parameter-apply kubernetes
#. Uninstall oidc-auth-apps. #. Uninstall oidc-auth-apps.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system application-remove oidc-auth-apps ~(keystone_admin)]$ system application-remove oidc-auth-apps
#. Clear the helm-override configuration. #. Clear the helm-override configuration.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system helm-override-update oidc-auth-apps dex kube-system --reset-values ~(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-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-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-show oidc-auth-apps oidc-client kube-system
#. Remove secrets that contain certificate data. #. Remove secrets that contain certificate data.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl delete secret local-dex.tls -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 dex-client-secret -n kube-system
~(keystone_admin)$ kubectl delete secret wadcert -n kube-system ~(keystone_admin)]$ kubectl delete secret wadcert -n kube-system
#. Remove any |RBAC| RoleBindings added for |OIDC| users and/or groups. #. Remove any |RBAC| RoleBindings added for |OIDC| users and/or groups.

4
doc/source/security/kubernetes/disable-pod-security-policy-checking.rst
View File

@@ -16,12 +16,12 @@ disable pod security policy checking.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-delete <uuid> ~(keystone_admin)]$ system service-parameter-delete <uuid>
#. Apply the Kubernetes system parameters. #. Apply the Kubernetes system parameters.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-apply kubernetes ~(keystone_admin)]$ system service-parameter-apply kubernetes

4
doc/source/security/kubernetes/enable-https-access-for-starlingx-rest-and-web-server-endpoints.rst
View File

@@ -36,13 +36,13 @@ When secure HTTPS connectivity is enabled, HTTP is disabled.
.. code-block:: none .. 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: - To disable HTTPS for StarlingX REST and Web Server endpoints:
.. code-block:: none .. 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: - Use the following command to display HTTPS settings:

4
doc/source/security/kubernetes/enable-pod-security-policy-checking.rst
View File

@@ -13,13 +13,13 @@ Enable Pod Security Policy Checking
.. code-block:: none .. 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. #. Apply the Kubernetes system parameters.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system service-parameter-apply kubernetes ~(keystone_admin)]$ system service-parameter-apply kubernetes
#. View the automatically added pod security policies. #. View the automatically added pod security policies.

8
doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst
View File

@@ -32,7 +32,7 @@ repository, see |admintasks-doc|: :ref:`Setting up a Public Repository
.. code-block:: none .. 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 <TAG> with the tag #. Copy the cert-manager-acmesolver image, and replace <TAG> with the tag
you want to copy from previous step. you want to copy from previous step.
@@ -53,7 +53,7 @@ repository, see |admintasks-doc|: :ref:`Setting up a Public Repository
.. code-block:: none .. code-block:: none
~(keystone_admin)$ cat <<EOF > cm-override-values.yaml ~(keystone_admin)]$ cat <<EOF > cm-override-values.yaml
acmesolver: acmesolver:
image: image:
repository: registry.local:9001/public/cert-manager-acmesolver 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 .. 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. #. Reapply cert-manager.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system application-apply cert-manager ~(keystone_admin)]$ system application-apply cert-manager

23
doc/source/security/kubernetes/estabilish-credentials-for-linux-user-accounts.rst Normal file
View File

@@ -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 <starlingx-openstack-kubernetes-from-stsadmin-account-login>`
- :ref:`For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account Login <establish-keystone-credentials-from-a-linux-account>`
- :ref:`For Kubernetes CLI from a Local LDAP Linux Account Login <kubernetes-cli-from-local-ldap-linux-account-login>`

144
doc/source/security/kubernetes/establish-keystone-credentials-from-a-linux-account.rst
View File

@@ -2,12 +2,13 @@
.. fan1552681866651 .. fan1552681866651
.. _establish-keystone-credentials-from-a-linux-account: .. _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 You can establish Keystone credentials for executing StarlingX and Platform
an LDAP account created using :command:`ldapusersetup`. OpenStack |CLIs| for a local |LDAP| user, if required; this is not setup by
default.
.. contents:: .. contents::
:local: :local:
@@ -19,110 +20,43 @@ For more information about :command:`ldapusersetup`, see :ref:`Create LDAP
Linux Accounts <create-ldap-linux-accounts>`. Linux Accounts <create-ldap-linux-accounts>`.
User accounts created using :command:`ldapusersetup` have access to the User accounts created using :command:`ldapusersetup` have access to the
Keystone CLI as part of the shell. To list the available commands, type StarlingX |CLIs| \(system, fm, sw-patch, dcmanager, etc.\) and the platform
**?** at the command line: '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 - You must have a platform Keystone user account. For more information about
env grep keystone lsudo rm system cd cp creating Keystone users, managing keystone projects, users and roles, see
exit ll man openstack scp vim cut export `https://docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html
help lpath env passwd sftp kubectl helm <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 - It is recommended to use the same username for both your local |LDAP| user
Keystone credentials for the duration of the session: 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 .. rubric:: |proc|
same script at any time during the session as follows:
.. 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 <http://docs.openstack.org/>`__.
Any Keystone credentials created by the script persist for the duration of #. \(Method 2\) Add the required environment variables manually into a
the session. This includes credentials added by previous invocations of the wrcprc.sh file and use this to source the required environment within your
script in the same session. 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:: .. note::
The Keystone user must be a member of a Keystone tenant. This is For security and reliability, add all the variables.
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
<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:
**OS\_USERNAME** **OS\_USERNAME**
the Keystone user name the Keystone user name
@@ -149,20 +83,4 @@ You can also establish Keystone credentials using the following methods:
the interface the interface
**OS\_REGION\_NAME** **OS\_REGION\_NAME**
the Keystone 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.

71
doc/source/security/kubernetes/https-access-overview.rst
View File

@@ -12,38 +12,19 @@ external |prod| service endpoints.
These include: 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:: .. contents::
:local: :local:
:depth: 1 :depth: 1
.. note:: You can also add a trusted Certificate Authority \(CA\) for the |prod| system.
Only self-signed or Root |CA|-signed certificates are supported for the
above |prod| service endpoints. See `https://en.wikipedia.org/wiki/X.509
<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.
.. _https-access-overview-section-N10048-N10024-N10001: .. _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 configured to accept the self-signed certificate without verifying it. This
is called insecure mode. is called insecure mode.
For secure-mode connections, a Root |CA|-signed certificate and key are For secure-mode connections, an intermediate or Root |CA|-signed certificate
required. The use of a Root |CA|-signed certificate is strongly recommended. and key are required. The use of an intermediate or Root |CA|-signed
Refer to the documentation for the external Root |CA| that you are using, on certificate is strongly recommended. Refer to the documentation for the
how to create public certificate and private key pairs, signed by a Root |CA|, external intermediate or Root |CA| that you are using, on how to create public
for HTTPS. 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 You can update the certificate and key used by |prod| for the
REST and Web Server endpoints at any time after installation. REST and Web Server endpoints at any time after installation.
@@ -84,15 +66,16 @@ hosts.
Kubernetes Kubernetes
---------- ----------
For the Kubernetes API Server, HTTPS is always enabled. Similarly, by For the Kubernetes API Server, HTTPS is always enabled. You must use a Root CA
default, a self-signed certificate and key is generated and installed for certificate; intermediate CA certificates are not supported by upstream
the Kubernetes Root |CA| certificate and key. This Kubernetes Root |CA| is Kubernetes. By default, a self-signed certificate and key is generated and
used to create and sign various certificates used within Kubernetes, installed for the Kubernetes Root |CA| certificate and key. This Kubernetes
including the certificate used by the kube-apiserver API endpoint. 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 It is recommended that you update the Kubernetes Root |CA| and with a custom
custom Root |CA| certificate and key, generated by yourself, and trusted by Root |CA| certificate and key, generated by yourself, and trusted by your
external servers connecting to |prod|'s Kubernetes API endpoint. |prod|'s external servers connecting to |prod|'s Kubernetes API endpoint. The |prod|'s
Kubernetes Root |CA| is configured as part of the bootstrap during Kubernetes Root |CA| is configured as part of the bootstrap during
installation. installation.
@@ -103,13 +86,13 @@ installation.
Local Docker Registry Local Docker Registry
--------------------- ---------------------
For the Local Docker Registry, HTTPS is always enabled. Similarly, by For the Local Docker Registry, HTTPS is always enabled. Similarly, by default,
default, a self-signed certificate and key is generated and installed for a self-signed certificate and key is generated and installed for this endpoint.
this endpoint. However, it is recommended that you update the certificate However, it is recommended that you update the certificate used after
used after installation with a Root |CA|-signed certificate and key. Refer to installation with an intermediate or Root |CA|-signed certificate and key.
the documentation for the external Root |CA| that you are using, on how to Refer to the documentation for the external intermediate or Root |CA| that you
create public certificate and private key pairs, signed by a Root |CA|, for are using, on how to create public certificate and private key pairs, signed by
HTTPS. a Root |CA|, for HTTPS.
.. _https-access-overview-section-N10086-N10024-N10001: .. _https-access-overview-section-N10086-N10024-N10001:

8
doc/source/security/kubernetes/index.rst
View File

@@ -9,7 +9,11 @@ System Accounts
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1
types-of-system-accounts
overview-of-system-accounts overview-of-system-accounts
kube-service-account
keystone-accounts
remote-windows-active-directory-accounts
Linux User Accounts Linux User Accounts
******************* *******************
@@ -23,6 +27,9 @@ Linux User Accounts
remote-access-for-linux-accounts remote-access-for-linux-accounts
password-recovery-for-linux-user-accounts password-recovery-for-linux-user-accounts
establish-keystone-credentials-from-a-linux-account 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 Kubernetes Service Accounts
*************************** ***************************
@@ -68,6 +75,7 @@ Access the System
install-the-kubernetes-dashboard install-the-kubernetes-dashboard
security-rest-api-access security-rest-api-access
connect-to-container-registries-through-a-firewall-or-proxy connect-to-container-registries-through-a-firewall-or-proxy
using-container-backed-remote-clis-and-clients
*************************** ***************************
Manage Non-Admin Type Users Manage Non-Admin Type Users

8
doc/source/security/kubernetes/install-portieris.rst
View File

@@ -20,7 +20,7 @@ You can install Portieris on |prod| from the command line.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system application-upload /usr/local/share/applications/helm/portieris-<version>.tgz ~(keystone_admin)]$ system application-upload /usr/local/share/applications/helm/portieris-<version>.tgz
#. Set caCert helm overrides if applicable. #. Set caCert helm overrides if applicable.
@@ -36,19 +36,19 @@ You can install Portieris on |prod| from the command line.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ echo 'caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURYVENDQWtXZ0F3SUJBZ0lKQUpjVHBXcTk4SWNSTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4Q3pBSkJnTlYKQkFZVEFrRlZNUk13RVFZRFZRUUlEQXBUYjIxbExWTjBZWFJsTVNFd0h3WURWUVFLREJoSmJuUmxjbTVsZENCWAphV1JuYVhSeklGQjBlU0JNZEdRd0hoY05NVGd3T0RFMk1qQXlPREl3V2hjTk1qRXdOakExTWpBeU9ESXdXakJGCk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkRYwWlRFaE1COEdBMVVFQ2d3WVNXNTAKWlhKdVpYUWdWMmxrWjJsMGN5QlFkSGtnVEhSa01JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQgpDZ0tDQVFFQXV4YXJMaVdwMDVnbG5kTWRsL1o3QmhySDFPTFNTVTcwcm9mV3duTmNQS3hsOURmVVNWVTZMTDJnClppUTFVZnA4TzFlVTJ4NitPYUxxekRuc2xpWjIxdzNXaHRiOGp2NmRFakdPdTg3eGlWWDBuSDBmSjF3cHFBR0UKRkVXekxVR2dJM29aUDBzME1Sbm1xVDA4VWZ6S0hCaFgvekNvNHMyVm9NcWxRNyt0Qjc2dTA3V3NKYQ0RFlQVwprR2tFVmRMSk4rWWcwK0pLaisvVU9kbE5WNDB2OE1ocEhkbWhzY1QyakI3WSszT0QzeUNxZ1RjRzVDSDQvK3J6CmR4Qjk3dEpMM2NWSkRQWTVNQi9XNFdId2NKRkwzN1p1M0dVdmhmVGF3NVE0dS85cTFkczgrVGFYajdLbWUxSzcKQnYyMTZ5dTZiN3M1ckpHU2lEZ0p1TWFNcm5YajFRSURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVyQndhbTAreApydUMvY3Vpbkp1RlM4Y1ZibjBBd0h3WURWUjBqQkJnd0ZvQVVyQndhbTAreHJ1Qy9jdWluSnVGUzhjVmJuMEF3CkRBWURWUjBUQFVd0F3RUIvekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZzJ5aEFNazVJUlRvOWZLc1IvMXkKMXJ5NzdSWU5KN1R2dTB0clltRElBMVRaanFtanlncFFiSmlGb0FPa255eHYveURLU0x6TXFNU2JIb0I1K1BhSQpnTERub0F6SnYxbzg3OEpkVllURjIyS2RUTU5wNWtITXVGMnpSTFFxc2lvenJQSUpWMDlVb2VHeHpPQ1pkYzZBCnpUblpCSy9DVTlRcnhVdzhIeDV6SEFVcHdVcGxONUE4MVROUmlMYVFVTXB5dzQ4Y08wNFcyOWY1aFA2aGMwVDMKSDJpU212OWY2K3Q5TjBvTTFuWVh1blgwWNJZll1aERmQy83c3N3eDhWcW5uTlNMN0lkQkhodGxhRHJGRXBzdQpGZzZOODBCbGlDclJiN2FPcUk4TWNjdzlCZW9UUk9uVGxVUU5RQkEzTjAyajJvTlhYL2loVHQvZkhNYlZGUFRQCi9nPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' > caCert.yaml ~(keystone_admin)]$ echo 'caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURYVENDQWtXZ0F3SUJBZ0lKQUpjVHBXcTk4SWNSTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4Q3pBSkJnTlYKQkFZVEFrRlZNUk13RVFZRFZRUUlEQXBUYjIxbExWTjBZWFJsTVNFd0h3WURWUVFLREJoSmJuUmxjbTVsZENCWAphV1JuYVhSeklGQjBlU0JNZEdRd0hoY05NVGd3T0RFMk1qQXlPREl3V2hjTk1qRXdOakExTWpBeU9ESXdXakJGCk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkRYwWlRFaE1COEdBMVVFQ2d3WVNXNTAKWlhKdVpYUWdWMmxrWjJsMGN5QlFkSGtnVEhSa01JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQgpDZ0tDQVFFQXV4YXJMaVdwMDVnbG5kTWRsL1o3QmhySDFPTFNTVTcwcm9mV3duTmNQS3hsOURmVVNWVTZMTDJnClppUTFVZnA4TzFlVTJ4NitPYUxxekRuc2xpWjIxdzNXaHRiOGp2NmRFakdPdTg3eGlWWDBuSDBmSjF3cHFBR0UKRkVXekxVR2dJM29aUDBzME1Sbm1xVDA4VWZ6S0hCaFgvekNvNHMyVm9NcWxRNyt0Qjc2dTA3V3NKYQ0RFlQVwprR2tFVmRMSk4rWWcwK0pLaisvVU9kbE5WNDB2OE1ocEhkbWhzY1QyakI3WSszT0QzeUNxZ1RjRzVDSDQvK3J6CmR4Qjk3dEpMM2NWSkRQWTVNQi9XNFdId2NKRkwzN1p1M0dVdmhmVGF3NVE0dS85cTFkczgrVGFYajdLbWUxSzcKQnYyMTZ5dTZiN3M1ckpHU2lEZ0p1TWFNcm5YajFRSURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVyQndhbTAreApydUMvY3Vpbkp1RlM4Y1ZibjBBd0h3WURWUjBqQkJnd0ZvQVVyQndhbTAreHJ1Qy9jdWluSnVGUzhjVmJuMEF3CkRBWURWUjBUQFVd0F3RUIvekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZzJ5aEFNazVJUlRvOWZLc1IvMXkKMXJ5NzdSWU5KN1R2dTB0clltRElBMVRaanFtanlncFFiSmlGb0FPa255eHYveURLU0x6TXFNU2JIb0I1K1BhSQpnTERub0F6SnYxbzg3OEpkVllURjIyS2RUTU5wNWtITXVGMnpSTFFxc2lvenJQSUpWMDlVb2VHeHpPQ1pkYzZBCnpUblpCSy9DVTlRcnhVdzhIeDV6SEFVcHdVcGxONUE4MVROUmlMYVFVTXB5dzQ4Y08wNFcyOWY1aFA2aGMwVDMKSDJpU212OWY2K3Q5TjBvTTFuWVh1blgwWNJZll1aERmQy83c3N3eDhWcW5uTlNMN0lkQkhodGxhRHJGRXBzdQpGZzZOODBCbGlDclJiN2FPcUk4TWNjdzlCZW9UUk9uVGxVUU5RQkEzTjAyajJvTlhYL2loVHQvZkhNYlZGUFRQCi9nPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' > caCert.yaml
#. Apply the override file. #. Apply the override file.
.. code-block:: none .. 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. #. Apply the application.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system application-apply portieris ~(keystone_admin)]$ system application-apply portieris

18
doc/source/security/kubernetes/install-the-kubernetes-dashboard.rst
View File

@@ -29,7 +29,7 @@ Dashboard.
.. code-block:: none .. 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. #. Create a certificate for use by the Kubernetes Dashboard.
@@ -43,20 +43,20 @@ Dashboard.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ cd /home/sysadmin ~(keystone_admin)]$ cd /home/sysadmin
~(keystone_admin)$ mkdir -p /home/sysadmin/kube/dashboard/certs ~(keystone_admin)]$ mkdir -p /home/sysadmin/kube/dashboard/certs
#. Create the certificate. #. Create the certificate.
.. code-block:: none .. 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=<FQDN>" ~(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=<FQDN>"
where: where:
**<FQDN>** **<FQDN>**
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. #. Create a kubernetes secret for holding the certificate and private key.
@@ -73,7 +73,7 @@ Dashboard.
.. code-block:: none .. 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. #. Edit the file.
@@ -98,18 +98,18 @@ Dashboard.
.. code-block:: none .. 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. #. Patch the kubernetes dashboard service to type=NodePort and port=30000.
.. code-block:: none .. 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. #. Test the Kubernetes Dashboard deployment.
The Kubernetes Dashboard is listening at port 30000 on the machine 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://<fqdn>:30000 #. Access the dashboard at https://<fqdn>:30000

18
doc/source/security/kubernetes/install-update-the-starlingx-rest-and-web-server-certificate.rst
View File

@@ -12,16 +12,18 @@ administration server.
.. rubric:: |prereq| .. rubric:: |prereq|
Obtain a Root |CA|-signed certificate and key from a trusted Root |CA|. Obtain an intermediate or Root |CA|-signed certificate and key from a trusted
Refer to the documentation for the external Root |CA| that you are using, intermediate or Root |CA|. Refer to the documentation for the external
on how to create public certificate and private key pairs, signed by a Root Intermediate or Root |CA| that you are using, on how to create public
|CA|, for HTTPS. certificate and private key pairs, signed by intermediate or a Root |CA|, for
HTTPS.
.. xbooklink .. xbooklink
For lab purposes, see :ref:`Locally Creating Certificates For lab purposes, see :ref:`Locally Creating Certificates
<creating-certificates-locally-using-openssl>` for how to create a test <creating-certificates-locally-using-openssl>` 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, Put the |PEM| encoded versions of the certificate and key in a single file,
and copy the file to the controller host. and copy the file to the controller host.
@@ -34,13 +36,13 @@ and copy the file to the controller host.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-install <pathTocertificateAndKey> ~(keystone_admin)]$ system certificate-install -m ssl <pathTocertificateAndKey>
where: where:
**<pathTocertificateAndKey>** **<pathTocertificateAndKey>**
is the path to the file containing both the Root |CA|-signed certificate is the path to the file containing both the intermediate or Root
and private key to install. |CA|-signed certificate and private key to install.

6
doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst
View File

@@ -10,7 +10,7 @@ Isolate StarlingX's Internal Cloud Management Network
only the hosts on the cluster. only the hosts on the cluster.
For information on internal networks, see the :ref:`StarlingX Planning Guide For information on internal networks, see the :ref:`StarlingX Planning Guide
<overview-of-starlingx-planning>`. The network should be configured as a <overview-of-starlingx-planning>` should be configured as a private network
private network visible to only the hosts on the cluster. Proper switch visible to only the hosts on the cluster. Proper switch configuration is
configuration is required to achieve the isolation. required to achieve the isolation.

14
doc/source/security/kubernetes/keystone-accounts.rst Normal file
View File

@@ -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 <about-keystone-accounts>` for more details.

14
doc/source/security/kubernetes/kube-service-account.rst Normal file
View File

@@ -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 <kubernetes-service-accounts>` for more
details.

62
doc/source/security/kubernetes/kubernetes-cli-from-local-ldap-linux-account-login.rst Normal file
View File

@@ -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 <create-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
<create-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 <ldapusername>
#. 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.

14
doc/source/security/kubernetes/kubernetes-root-ca-certificate.rst
View File

@@ -20,6 +20,18 @@ servers connecting to the |prod|'s Kubernetes API endpoint.
<creating-certificates-locally-using-openssl>` for how to create a <creating-certificates-locally-using-openssl>` for how to create a
private Root |CA| certificate and key. 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 <k8s\_root\_ca\_cert> and Use the bootstrap override values <k8s\_root\_ca\_cert> and
<k8s\_root\_ca\_key>, as part of the installation procedure to specify the <k8s\_root\_ca\_key>, as part of the installation procedure to specify the
certificate and key for the Kubernetes root |CA|. 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 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. 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 See the step :ref:`2.b
<security-install-kubectl-and-helm-clients-directly-on-a-host>` in <security-install-kubectl-and-helm-clients-directly-on-a-host>` in

38
doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst
View File

@@ -12,22 +12,19 @@ cluster using standard Linux commands.
.. _local-and-ldap-linux-user-accounts-ul-zrv-zwf-mmb: .. _local-and-ldap-linux-user-accounts-ul-zrv-zwf-mmb:
Local Linux user accounts should NOT be configured, only use local LDAP - Local Linux user accounts should NOT be configured, only use local |LDAP|
accounts for internal system purposes that would usually not be created by accounts for internal system purposes that would usually not be created by
an end-user. an end-user.
Password changes are not enforced automatically on the first login, and - Password changes are not enforced automatically on the first login, and
they are not propagated by the system \(only for 'sysadmin'\). 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. 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. to the sudoers list and can acquire OpenStack administration credentials.
- The initial password must be changed immediately upon the first login. - 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. of the target host.
.. note:: .. note::
For security reasons, it is recommended that ONLY admin level users For security reasons, it is recommended that ONLY admin level users be
be allowed to SSH to the nodes of |prod|. Non-admin level users allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
should strictly use remote CLIs or remote web GUIs. strictly use remote |CLIs| or remote web GUIs.
Operational complexity: Operational complexity:
@@ -54,14 +50,14 @@ Operational complexity:
- Passwords aging is automatically configured. - 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 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 accounts must be used from the console ports of the hosts; no |SSH| access
allowed. 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 Keystone user support. It provides an interactive method for setting up
LDAP Linux user accounts with access to OpenStack commands. You can assign |LDAP| Linux user accounts with access to OpenStack commands. You can
a limited shell or a bash shell. assign a limited shell or a bash shell.

21
doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst
View File

@@ -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 allowed to SSH to the nodes of the |prod|. Non-admin level users should
strictly use remote CLIs or remote web GUIs. strictly use remote CLIs or remote web GUIs.
Apart from being centrally managed, LDAP user accounts behave as any local Apart from being centrally managed, LDAP user accounts behave as any local user
user account. They can be added to the sudoers list, and can acquire account. They can be added to the sudoers list, and can acquire Keystone
Keystone administration credentials when executing on the active controller. 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: 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. 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 The following LDAP user accounts are available by default on newly deployed
hosts, regardless of their personality: hosts, regardless of their personality:
@@ -57,9 +64,9 @@ hosts, regardless of their personality:
A cloud administrative account, comparable to the default **admin** A cloud administrative account, comparable to the default **admin**
account used in the web management interface. account used in the web management interface.
This user account operates on a restricted Linux shell, with very This user account has access to all native Linux commands not requiring
limited access to native Linux commands. However, the shell is root or sudo privileges, and it's shell is preconfigured to have
preconfigured to have administrative access to StarlingX commands. administrative access to StarlingX commands.
**admin** **admin**
A host administrative account. It has access to all native Linux 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 **operator** account enables access to the cloud deployment only, without
giving unabated sudo access to the entire system. giving unabated sudo access to the entire system.
.. seealso::
:ref:`Creating LDAP Linux Accounts <create-ldap-linux-accounts>`

15
doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst
View File

@@ -6,11 +6,11 @@
Local Linux Account for 'sysadmin' Local Linux Account for 'sysadmin'
================================== ==================================
This is a local, per-host, sudo-enabled account created automatically when This is a local, per-host, sudo-enabled account created automatically when a
a new host is provisioned. 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 system administrator as it has extended
extended privileges. privileges.
.. _local-linux-account-for-sysadmin-ul-zgk-1wf-mmb: .. _local-linux-account-for-sysadmin-ul-zgk-1wf-mmb:
@@ -21,8 +21,7 @@ extended privileges.
- After five consecutive unsuccessful login attempts, further attempts - After five consecutive unsuccessful login attempts, further attempts
are blocked for about five minutes. are blocked for about five minutes.
Operational complexity: None. Operational complexity: None. The above security hardening features are set by
default \(see :ref:`System Account Password Rules
The above security hardening features are set by default \(see :ref:`System <system-account-password-rules>` for password rules\).
Account Password Rules <system-account-password-rules>` for password rules\).

32
doc/source/security/kubernetes/manage-keystone-accounts.rst
View File

@@ -11,21 +11,30 @@ See
<https://docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html>`_ <https://docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html>`_
_ for details on managing Keystone projects, users, and roles. _ for details on managing Keystone projects, users, and roles.
.. note::
All Kubernetes accounts are subject to system password rules. For All Kubernetes accounts are subject to system password rules. For complete
complete details on password rules, see :ref:`System Account Password details on password rules, see :ref:`System Account Password Rules
Rules <starlingx-system-accounts-system-account-password-rules>`. <starlingx-system-accounts-system-account-password-rules>`.
If you are using when changing the keystone 'admin' user password, you must:
.. _managing-keystone-accounts-ol-wyq-l4d-mmb: .. _managing-keystone-accounts-ol-wyq-l4d-mmb:
If using the FIXME: REMOVE, when changing the Keystone 'admin' user #. If the **deployment-config.yaml** file has been moved off-box for security
password, you must: reasons, upload the file back to the system to be updated.
#. Update the password in the 'system-endpoint' secret in the FIXME: .. warning::
REMOVE's deployment-config.yaml file, with the new Keystone 'admin' The **deployment-config.yaml** file includes sensitive information
user password. \(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 .. code-block:: none
@@ -37,4 +46,5 @@ password, you must:
kubectl apply -f deployment-config.yaml 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.

8
doc/source/security/kubernetes/obtain-the-authentication-token-using-the-browser.rst
View File

@@ -64,21 +64,21 @@ refresh-token using the **oidc-auth-apps** |OIDC| client web interface.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ TOKEN=<ID_token_string> ~(keystone_admin)]$ TOKEN=<ID_token_string>
~(keystone_admin)$ kubectl config set-credentials testuser --token $TOKEN ~(keystone_admin)]$ kubectl config set-credentials testuser --token $TOKEN
#. Switch to the Kubernetes context for the user, by using the following #. Switch to the Kubernetes context for the user, by using the following
command, for example: command, for example:
.. code-block:: none .. 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 #. Run the following command to test that the authentication token
validates correctly: validates correctly:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl get pods --all-namespaces ~(keystone_admin)]$ kubectl get pods --all-namespaces

6
doc/source/security/kubernetes/obtain-the-authentication-token-using-the-oidc-auth-shell-script.rst
View File

@@ -59,13 +59,13 @@ credential for the user in the **kubectl** config file.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ oidc-auth -c <ip> -u <username> ~(keystone_admin)]$ oidc-auth -c <ip> -u <username>
For example, For example,
.. code-block:: none .. code-block:: none
~(keystone_admin)$ oidc-auth -c <OAM_ip_address> -u testuser ~(keystone_admin)]$ oidc-auth -c <OAM_ip_address> -u testuser
Password: Password:
Login succeeded. Login succeeded.
Updating kubectl config ... Updating kubectl config ...
@@ -75,7 +75,7 @@ credential for the user in the **kubectl** config file.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ oidc-auth -b <connector-id> -c <ip> -u <username> ~(keystone_admin)]$ oidc-auth -b <connector-id> -c <ip> -u <username>

79
doc/source/security/kubernetes/overview-of-system-accounts.rst
View File

@@ -2,71 +2,34 @@
.. lgd1552571882796 .. lgd1552571882796
.. _overview-of-system-accounts: .. _overview-of-system-accounts:
===================================== ==================
Overview of StarlingX System Accounts Linux UserAccounts
===================================== ==================
A brief description of the system accounts available in a |prod| system. 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.
------------------------ See :ref:`The sysadmin Account <the-sysadmin-account>` for more details.
Types of System Accounts
------------------------
- **sysadmin Local Linux Account** **Local Linux User Accounts**
This is a local, per-host, account created automatically when a new host Local Linux User Accounts should NOT be created since they are used for
is provisioned. This account has extended privileges and is used by the internal system purposes.
system administrator.
- **Local Linux User Accounts** **Local LDAP Linux User Accounts**
These are local, regular Linux user accounts that are typically used for These are local LDAP accounts that are centrally managed across all hosts
internal system purposes and generally should not be created by an end in the cluster. These accounts are intended to provide additional admin
user. 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, See :ref:`Local LDAP Linux User Accounts <local-ldap-linux-user-accounts>`
it is better to configure local LDAP Linux accounts. for more details.
- **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|.
.. note:: .. note::
For security reasons, it is recommended that ONLY admin level users For security reasons, it is recommended that ONLY admin level users be
be allowed to SSH to the nodes of the |prod|. Non-admin level users allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
should strictly use remote CLIs or remote web GUIs.. 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.

8
doc/source/security/kubernetes/password-recovery.rst
View File

@@ -6,6 +6,10 @@
Password Recovery Password Recovery
================= =================
.. rubric:: |context|
This section describes how to change or reset a Keystone user password.
.. rubric:: |proc| .. rubric:: |proc|
- Do one of the following to change a Keystone admin user password at any - Do one of the following to change a Keystone admin user password at any
@@ -18,7 +22,7 @@ Password Recovery
.. code-block:: none .. code-block:: none
~(keystone_admin)$ openstack user password set ~(keystone_admin)]$ openstack user password set
.. warning:: .. warning::
Both controller nodes must be locked and unlocked after changing Both controller nodes must be locked and unlocked after changing
@@ -30,7 +34,7 @@ Password Recovery
.. code-block:: none .. code-block:: none
~(keystone_admin)$ openstack user set --password <temp_password> <user> ~(keystone_admin)]$ openstack user set --password <temp_password> <user>
where <user> is the username and <temp\_password> is a temporary password. where <user> is the username and <temp\_password> is a temporary password.

11
doc/source/security/kubernetes/remote-access-for-linux-accounts.rst
View File

@@ -6,15 +6,16 @@
Remote Access for Linux Accounts 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:: .. note::
For security reasons, it is recommended that ONLY admin level users be 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 allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
strictly use remote CLIs or remote web GUIs. strictly use remote |CLIs| or remote web GUIs.
Specifying the OAM floating IP address as the target establishes a Specifying the |OAM| floating IP address as the target establishes a
connection to the currently active controller; however, if the OAM floating connection to the currently active controller; however, if the |OAM| floating
IP address moves from one controller node to another, the ssh session is IP address moves from one controller node to another, the ssh session is
blocked. To ensure access to a particular controller regardless of its blocked. To ensure access to a particular controller regardless of its
current role, specify the controller physical address instead. current role, specify the controller physical address instead.

15
doc/source/security/kubernetes/remote-windows-active-directory-accounts.rst Normal file
View File

@@ -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
<overview-of-windows-active-directory>` for more details.

30
doc/source/security/kubernetes/remove-portieris.rst
View File

@@ -15,7 +15,7 @@ system.
.. code-block:: none .. 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. #. Delete kubernetes resources not automatically removed in the previous step.
@@ -23,11 +23,11 @@ system.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl delete clusterroles.rbac.authorization.k8s.io 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 clusterrolebindings.rbac.authorization.k8s.io admission-portieris-webhook
~(keystone_admin)$ kubectl delete -n portieris secret/portieris-certs ~(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 cm/image-policy-crds
~(keystone_admin)$ kubectl delete -n portieris serviceaccounts/portieris ~(keystone_admin)]$ kubectl delete -n portieris serviceaccounts/portieris
.. note:: .. note::
If this step is done before removing the application in step 1, the If this step is done before removing the application in step 1, the
@@ -37,19 +37,19 @@ system.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl delete MutatingWebhookConfiguration image-admission-config --ignore-not-found=true ~(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 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 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 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 clusterrolebindings.rbac.authorization.k8s.io admission-portieris-webhook --ignore-not-found=true
~(keystone_admin)$ kubectl delete ns/portieris --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)]$ helm delete portieris-portieris --purge --no-hooks
~(keystone_admin)$ system application-remove portieris ~(keystone_admin)]$ system application-remove portieris
#. Delete the application. #. Delete the application.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system application-delete portieris ~(keystone_admin)]$ system application-delete portieris

23
doc/source/security/kubernetes/secure-starlingx-rest-and-web-certificates-private-key-storage-with-tpm.rst
View File

@@ -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: .. _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 - Obtain an intermediate or Root |CA|-signed certificate and key from a
|CA|. Refer to the documentation for the external Root |CA| that you trusted intermediate or Root |CA|. Refer to the documentation for the
are using, on how to create public certificate and private key pairs, external intermediate or Root |CA| that you are using, on how to create
signed by a Root |CA|, for HTTPS. public certificate and private key pairs, signed by an intermediate or
Root-signed |CA|, for HTTPS.
.. xbooklink .. xbooklink
For lab purposes, see :ref:`Locally Creating Certificates For lab purposes, see :ref:`Locally Creating Certificates
<creating-certificates-locally-using-openssl>` for details on how to <creating-certificates-locally-using-openssl>` for details on how to create
create a test Root |CA| certificate and key, and use it to sign test a test intermediate or Root |CA| certificate and key, and use it to sign
certificates. test certificates.
Put the |PEM| encoded versions of the certificate and key in a Put the |PEM| encoded versions of the certificate and key in a
single file, and copy the file to the controller host. 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.
**<pathTocertificateAndKey>** **<pathTocertificateAndKey>**
is the path to the file containing both the Root |CA|-signed is the path to the file containing both the intermediate or Root
certificate and private key to install. |CA|-signed certificate and private key to install.
.. warning:: .. warning::
For security purposes, the utility deletes the provided SSL private For security purposes, the utility deletes the provided SSL private
@@ -159,7 +160,7 @@ scenario, you must reinstall the certificate:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-install -m tpm_mode ~(keystone_admin)]$ system certificate-install -m tpm_mode
<pathTocertificateAndKey> <pathTocertificateAndKey>
To disable the use of |TPM| to store the private key of the StarlingX REST To disable the use of |TPM| to store the private key of the StarlingX REST
@@ -168,5 +169,5 @@ option:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-install <pathTocertificateAndKey> ~(keystone_admin)]$ system certificate-install <pathTocertificateAndKey>

315
doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst
View File

@@ -6,14 +6,14 @@
Configure Container-backed Remote CLIs and Clients Configure Container-backed Remote CLIs and Clients
================================================== ==================================================
The command line can be accessed from remote computers running Linux, OSX, The |prod| command lines can be accessed from remote computers running Linux,
and Windows. MacOS, and Windows.
.. rubric:: |context| .. rubric:: |context|
This functionality is made available using a docker image for connecting to This functionality is made available using a docker container with
the |prod| remotely. This docker image is pulled as required by pre-installed CLIs and clients. The container's image is pulled as required by
configuration scripts. the remote CLI/client configuration scripts.
.. rubric:: |prereq| .. rubric:: |prereq|
@@ -22,6 +22,21 @@ more information on installing Docker, see
`https://docs.docker.com/install/ <https://docs.docker.com/install/>`__. `https://docs.docker.com/install/ <https://docs.docker.com/install/>`__.
For Windows remote clients, Docker is only supported on Windows 10. 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/
<https://docs.docker.com/engine/install/linux-postinstall/>`__
For Windows remote clients, you must run the following commands from a For Windows remote clients, you must run the following commands from a
Cygwin terminal. See `https://www.cygwin.com/ <https://www.cygwin.com/>`__ Cygwin terminal. See `https://www.cygwin.com/ <https://www.cygwin.com/>`__
for more information about the Cygwin project. 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 <PATH> variable tarball, extract it to any location and change the Windows <PATH> variable
to include its bin folder from the extracted winpty folder. to include its bin folder from the extracted winpty folder.
The following procedure shows how to configure the Container-backed Remote The following procedure shows how to configure the Container-backed Remote CLIs
CLIs and Clients for an admin user with cluster-admin clusterrole. If using and Clients for an admin user with cluster-admin clusterrole. If using a
a non-admin user such as one with role privileges only within a private non-admin user such as one with privileges only within a private namespace,
namespace, additional configuration is required in order to use additional configuration is required in order to use :command:`helm`.
:command:`helm`.
.. rubric:: |proc| .. 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. #. 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 You must configure a Kubernetes service account on the target system
and generate a configuration file based on that service account. 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. #. Set environment variables.
@@ -60,14 +83,14 @@ namespace, additional configuration is required in order to use
.. code-block:: none .. code-block:: none
% USER="admin-user" ~(keystone_admin)]$ USER="admin-user"
% OUTPUT_FILE="temp-kubeconfig" ~(keystone_admin)]$ OUTPUT_FILE="temp-kubeconfig"
#. Create an account definition file. #. Create an account definition file.
.. code-block:: none .. code-block:: none
% cat <<EOF > admin-login.yaml ~(keystone_admin)]$ cat <<EOF > admin-login.yaml
apiVersion: v1 apiVersion: v1
kind: ServiceAccount kind: ServiceAccount
metadata: metadata:
@@ -92,59 +115,54 @@ namespace, additional configuration is required in order to use
.. code-block:: none .. code-block:: none
% kubectl apply -f admin-login.yaml ~(keystone_admin)]$ kubectl apply -f admin-login.yaml
#. Store the token value. #. Store the token value.
.. code-block:: none .. 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. #. Store the |OAM| IP address.
.. code-block:: none
% source /etc/platform/openrc
#. 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 <oam\_ip> instead of <oam\_floating\_ip>. The #. AIO-SX uses <oam\_ip> instead of <oam\_floating\_ip>. The
following shell code ensures that <OAM\_IP> is assigned the correct following shell code ensures that <OAM\_IP> is assigned the correct
IP address. IP address.
.. code-block:: none .. 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}') OAM_IP=$(system oam-show |grep oam_ip| awk '{print $4}')
fi 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 .. code-block:: none
% if [[ $OAM_IP =~ .*:.* ]]; then ~(keystone_admin)]$ if [[ $OAM_IP =~ .*:.* ]]; then
OAM_IP="[${OAM_IP}]" OAM_IP="[${OAM_IP}]"
fi fi
#. Generate the temp-kubeconfig file. #. Generate the admin-kubeconfig file.
.. code-block:: none .. code-block:: none
% 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-cluster wrcp-cluster --server=https://${OAM_IP}:6443 --insecure-skip-tls-verify
% sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-credentials ${USER} --token=$TOKEN_DATA ~(keystone_admin)]$ 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 ~(keystone_admin)]$ 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} use-context ${USER}@wrcp-cluster
#. On the remote client, install the remote client tarball file from the #. Copy the remote client tarball file from the |prod| build servers
StarlingX CENGEN build servers.. to the remote workstation, and extract its content.
- The tarball is available from the |prod| area on the StarlingX CENGEN build servers. - 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. - You can extract the tarball's contents anywhere on your client system.
While it is not strictly required to extract the tarball before other .. parsed-literal::
steps, subsequent steps in this example copy files to the extracted
directories as a convenience when running configuration scripts.
#. Download the openrc file from the Horizon Web interface to the remote client. $ cd $HOME
$ tar xvf |prefix|-remote-clients-<version>.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. #. 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**. #. Navigate to **Project** \> **API Access** \> **Download Openstack RC file**.
#. Select **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 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 convenience, this example assumes that it is copied to the location of
the extracted tarball. the extracted tarball.
.. note:: .. 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 the file to the remote workstation, otherwise, use the following
command to change permissions, :command:`chmod 666 temp\_kubeconfig`. 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. #. 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-<version>/
.. note:: #. Create a working directory that will be mounted by the container
For remote CLI commands that require local filesystem access, implementing the remote |CLIs|.
you can specify a working directory when running
:command:`configure\_client.sh` using the -w option. If no See the description of the :command:`configure\_client.sh` -w option
directory is specified, the location from which the :ref:`below
:command:`configure\_client.sh` was run is used for local file <security-configure-container-backed-remote-clis-and-clients>`
access by remote cli commands. This working directory is for more details.
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.
.. code-block:: none .. code-block:: none
$ mkdir -p $HOME/remote_wd $ mkdir -p $HOME/remote_cli_wd
$ ./configure_client.sh -t platform -r admin_openrc.sh -k temp-kubeconfig \
-w HOME/remote_wd
$ cd $HOME/remote_wd
By default, configure\_client.sh will use container images from #. Run the :command:`configure\_client.sh` script.
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
.. code-block:: none .. code-block:: none
$ ./configure_client.sh -t platform -r admin_openrc.sh -k $ ./configure_client.sh -t platform -r admin_openrc.sh -k
temp-kubeconfig -w HOME/remote_wd -p admin-kubeconfig -w HOME/remote_cli_wd -p
625619392498.dkr.ecr.us-west-2.amazonaws.com/starlingx/stx-platfo 625619392498.dkr.ecr.us-west-2.amazonaws.com/docker.io/starlingx/stx-platfo
rmclients:stx.4.0-v1.3.0 -a rmclients:stx.4.0-v1.3.0
625619392498.dkr.ecr.us-west-2.amazonaws.com/starlingx/stx-openst
ackclients:master-centos-stable-latest
If you are working with repositories that require authentication, If you specify repositories that require authentication, as shown
you must first perform a :command:`docker login` to that repository above, you must first remember to perform a :command:`docker login` to
before using remote clients. 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 default value is admin-openrc.sh.
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.
.. 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 The default value is temp-kubeconfig.
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#
.. note:: **-o**
Some commands used by remote CLI are designed to leave you in a shell prompt, for example: 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 .. 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 <pod_name> -- /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 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.
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 <FORCE\_SHELL> or <FORCE\_NO\_SHELL>
variables before the command.
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 <pod_name> -- /bin/bash After configuring the platform's container-backed remote CLIs/clients, the
root@myclient:/home/user/remote_wd# FORCE_NO_SHELL=true kubectl exec <pod_name> -- ls 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. .. note::
Consider adding this command to your .login or shell rc file, such
#. If you need to run a remote CLI command that references a local file, that your shells will automatically be initialized with the environment
then that file must be copied to or created in the working directory variables and aliases for the remote |CLI| commands.
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"
See :ref:`Using Container-backed Remote CLIs and Clients <using-container-backed-remote-clis-and-clients>` for details.
**Related information**
.. seealso:: .. seealso::
:ref:`Using Container-backed Remote CLIs and Clients
<using-container-backed-remote-clis-and-clients>`
:ref:`Install Kubectl and Helm Clients Directly on a Host :ref:`Install Kubectl and Helm Clients Directly on a Host
<security-install-kubectl-and-helm-clients-directly-on-a-host>` <security-install-kubectl-and-helm-clients-directly-on-a-host>`

4
doc/source/security/kubernetes/security-default-firewall-rules.rst
View File

@@ -16,7 +16,7 @@ You can view the configured firewall rules with the following command:
.. code-block:: none .. code-block:: none
~(keystone_admin)$ kubectl describe globalnetworkpolicy ~(keystone_admin)]$ kubectl describe globalnetworkpolicy
Name: controller-oam-if-gnp Name: controller-oam-if-gnp
Namespace: Namespace:
Labels: <none> Labels: <none>
@@ -85,7 +85,7 @@ You can view the configured firewall rules with the following command:
Where: Where:
.. _security-default-firewall-rules-d477e47: .. _security-default-firewall-rules-d488e47:
.. table:: .. table::

10
doc/source/security/kubernetes/security-firewall-options.rst
View File

@@ -6,25 +6,25 @@
Firewall Options 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 additional Kubernetes Network Policies in order to augment or override the
default rules. default rules.
The |prod| firewall uses the Kubernetes Network Policies \(using the Calico 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: 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. - Egress traffic is always accepted.
- |SM| 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 You can introduce custom rules by creating and installing custom Kubernetes

10
doc/source/security/kubernetes/security-hardening-firewall-options.rst
View File

@@ -18,13 +18,13 @@ A minimal set of rules is always applied before any custom rules, as follows:
.. _firewall-options-ul-gjq-k1g-mmb: .. _firewall-options-ul-gjq-k1g-mmb:
- Non-OAM traffic is always accepted. - Non-|OAM| traffic is always accepted.
- Egress traffic is always accepted. - Egress traffic is always accepted.
- |SM| traffic is always accepted. - |SM| traffic is always accepted.
- SSH traffic is always accepted. - |SSH| traffic is always accepted.
.. note:: .. note::
It is recommended to disable port 80 when HTTPS is enabled for external 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: .. _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 For more information, see :ref:`Firewall Options
<security-firewall-options>`. <security-firewall-options>`.
@@ -47,9 +47,9 @@ Operational complexity:
Default Firewall Rules 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. rules are recommended for most applications.
For a complete listing, see :ref:`Default Firewall Rules For a complete listings, see :ref:`Default Firewall Rules
<security-default-firewall-rules>`. <security-default-firewall-rules>`.

3
doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst
View File

@@ -141,6 +141,9 @@ configuration is required in order to use :command:`helm`.
:ref:`Configure Container-backed Remote CLIs and Clients :ref:`Configure Container-backed Remote CLIs and Clients
<security-configure-container-backed-remote-clis-and-clients>` <security-configure-container-backed-remote-clis-and-clients>`
:ref:`Using Container-backed Remote CLIs and Clients
<using-container-backed-remote-clis-and-clients>`
:ref:`Configure Remote Helm Client for Non-Admin Users :ref:`Configure Remote Helm Client for Non-Admin Users
<configure-remote-helm-client-for-non-admin-users>` <configure-remote-helm-client-for-non-admin-users>`

51
doc/source/security/kubernetes/security-install-update-the-docker-registry-certificate.rst
View File

@@ -10,42 +10,42 @@ The local docker registry provides secure HTTPS access using the registry API.
.. rubric:: |context| .. rubric:: |context|
By default a self-signed certificate is generated at installation time for By default a self-signed certificate is generated at installation time for the
the registry API. For more secure access, a Root |CA|-signed certificate is registry API. For more secure access, an intermediate or Root |CA|-signed
strongly recommended. certificate is strongly recommended.
The Root |CA|-signed certificate for the registry must have at least the The intermediate or Root |CA|-signed certificate for the registry must have at
following |SANs|: DNS:registry.local, DNS:registry.central, IP least the following |SANs|: DNS:registry.local, DNS:registry.central, IP
Address:<oam-floating-ip-address>, IP Address:<mgmt-floating-ip-address>. Address:<oam-floating-ip-address>, IP Address:<mgmt-floating-ip-address>. Use
Use the :command:`system addrpool-list` command to get the |OAM| floating IP 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 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 additional DNS entry\(s\) that you have set up for your |OAM| floating IP
Address. Address.
Use the following procedure to install a Root |CA|-signed certificate to either Use the following procedure to install an intermediate or Root |CA|-signed
replace the default self-signed certificate or to replace an expired or soon certificate to either replace the default self-signed certificate or to replace
to expire certificate. an expired or soon to expire certificate.
.. rubric:: |prereq| .. rubric:: |prereq|
Obtain a Root |CA|-signed certificate and key from a trusted Root |CA|. Refer Obtain an intermediate or Root |CA|-signed certificate and key from a trusted
to the documentation for the external Root |CA| that you are using, on how to intermediate or Root |CA|. Refer to the documentation for the external Root
create public certificate and private key pairs, signed by a Root |CA|, for |CA| that you are using, on how to create public certificate and private key
HTTPS. pairs, signed by an intermediate or Root |CA|, for HTTPS.
For lab purposes, see Appendix A for how to create a test Root |CA| For lab purposes, see Appendix A for how to create a test intermediate or Root
certificate and key, and use it to sign test certificates. |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, Put the |PEM| encoded versions of the certificate and key in a single file,
and copy the file to the controller host. and copy the file to the controller host.
Also, obtain the certificate of the Root |CA| that signed the above Also, obtain the certificate of the intermediate or Root |CA| that signed the
certificate. above certificate.
.. rubric:: |proc| .. 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, #. In order to enable internal use of the docker registry certificate,
update the trusted |CA| list for this system with the Root |CA| associated update the trusted |CA| list for this system with the Root |CA| associated
@@ -53,14 +53,15 @@ certificate.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-install --mode ssl_ca ~(keystone_admin)]$ system certificate-install --mode ssl_ca
<pathTocertificate> <pathTocertificate>
where: where:
**<pathTocertificate>** **<pathTocertificate>**
is the path to the Root |CA| certificate associated with the docker is the path to the intermediate or Root |CA| certificate associated
registry Root |CA|-signed certificate. with the docker registry's intermediate or Root |CA|-signed
certificate.
#. Update the docker registry certificate using the #. Update the docker registry certificate using the
:command:`certificate-install` command. :command:`certificate-install` command.
@@ -69,13 +70,13 @@ certificate.
.. code-block:: none .. code-block:: none
~(keystone_admin)$ system certificate-install --mode docker_registry ~(keystone_admin)]$ system certificate-install --mode docker_registry
<pathTocertificateAndKey> <pathTocertificateAndKey>
where: where:
**<pathTocertificateAndKey>** **<pathTocertificateAndKey>**
is the path to the file containing both the docker registry is the path to the file containing both the docker registry's
certificate and private key to install. intermediate or Root CA-signed certificate and private key to install.

21
doc/source/security/kubernetes/starlingx-openstack-kubernetes-from-stsadmin-account-login.rst Normal file
View File

@@ -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

26
doc/source/security/kubernetes/starlingx-rest-api-applications-and-the-web-administration-server.rst
View File

@@ -13,25 +13,19 @@ StarlingX\) and the |prod| web administration server.
By default HTTPS access to StarlingX REST and Web Server's endpoints are By default HTTPS access to StarlingX REST and Web Server's endpoints are
disabled; i.e. accessible via HTTP only. 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:: .. note::
The default HTTPS X.509 certificates that are used by |prod-long| for Refer to the documentation for the external Intermediate or Root |CA| that
authentication are not signed by a known authority. For increased you are using, on how to create public certificate and private key pairs,
security, obtain, install, and use certificates that have been signed signed by an Intermediate or Root |CA|, for HTTPS.
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.
By default a self-signed certificate and key is generated and installed by For secure remote access, an intermediate or Root |CA|-signed certificate and
|prod| for the StarlingX REST and Web Server endpoints for evaluation key are required. The use of a Root |CA|-signed certificate is strongly
purposes. This certificate and key is installed by default when HTTPS recommended.
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.
You can update the certificate used for HTTPS access at any time. You can update the certificate used for HTTPS access at any time.

4
doc/source/security/kubernetes/starlingx-system-accounts-system-account-password-rules.rst
View File

@@ -12,7 +12,7 @@ The following rules apply to all System Accounts \(Local LDAP, sysadmin,
other Linux Accounts, and Keystone accounts\): 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. - 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 The following additional rules apply to Local Linux accounts only \(Local
LDAP, sysadmin, and other Linux accounts\): 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\) - Dictionary words or simple number sequences \(for example, 123 or 321\)
are not allowed are not allowed

2
doc/source/security/kubernetes/the-sysadmin-account.rst
View File

@@ -9,7 +9,7 @@ The sysadmin Account
This is a local, per-host, sudo-enabled account created automatically when a This is a local, per-host, sudo-enabled account created automatically when a
new host is provisioned. 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. extended privileges.
On controller nodes, this account is available even before :command:`ansible On controller nodes, this account is available even before :command:`ansible

25
doc/source/security/kubernetes/types-of-system-accounts.rst Normal file
View File

@@ -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 <overview-of-system-accounts>`
- :ref:`Kubernetes Service Accounts <kube-service-account>`
- :ref:`Keystone Accounts <keystone-accounts>`
- :ref:`Remote Windows Active Directory Accounts <remote-windows-active-directory-accounts>`
- :ref:`Linux User Accounts <overview-of-system-accounts>`

2
doc/source/security/kubernetes/uefi-secure-boot.rst
View File

@@ -27,6 +27,6 @@ Operational complexity:
- This must be done for each node before starting the installation. - 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
<overview-of-uefi-secure-boot>`. <overview-of-uefi-secure-boot>`.

158
doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst Normal file
View File

@@ -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
<security-configure-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 <pod_name> -- /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 <FORCE\_SHELL>
or <FORCE\_NO\_SHELL> variables before the command.
For example:
.. code-block:: none
root@myclient:/home/user/remote_cli_wd# FORCE_SHELL=true kubectl exec -ti <pod_name> -- /bin/bash
root@myclient:/home/user/remote_cli_wd# FORCE_NO_SHELL=true kubectl exec <pod_name> -- 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 /<someDir>/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
<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\_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
<security-configure-container-backed-remote-clis-and-clients>`
:ref:`Installing Kubectl and Helm Clients Directly on a Host
<security-install-kubectl-and-helm-clients-directly-on-a-host>`
:ref:`Configuring Remote Helm Client for Non-Admin Users
<configure-remote-helm-client-for-non-admin-users>`

2
doc/source/security/kubernetes/web-administration-login-timeout.rst
View File

@@ -12,6 +12,6 @@ out after 50 minutes \(the Keystone Token Expiry time\), regardless of activity.
Operational complexity: No additional configuration is required. Operational complexity: No additional configuration is required.
You can also block user access after a set number of failed login attempts as 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
<configure-horizon-user-lockout-on-failed-logins>`. <configure-horizon-user-lockout-on-failed-logins>`.

2
doc/source/shared/abbrevs.txt
View File

@@ -133,4 +133,4 @@
.. |VXLAN| replace:: :abbr:`VXLAN (Virtual eXtensible Local Area Network)` .. |VXLAN| replace:: :abbr:`VXLAN (Virtual eXtensible Local Area Network)`
.. |VXLANs| replace:: :abbr:`VXLANs (Virtual eXtensible Local Area Networks)` .. |VXLANs| replace:: :abbr:`VXLANs (Virtual eXtensible Local Area Networks)`
.. |XML| replace:: :abbr:`XML (eXtensible Markup Language)` .. |XML| replace:: :abbr:`XML (eXtensible Markup Language)`
.. |YAML| replace:: :abbr:`YAML (YAML Ain't Markup Language)` .. |YAML| replace:: :abbr:`YAML (YAML Ain't Markup Language)`

2
doc/source/usertasks/kubernetes/kubernetes-user-tutorials-installing-kubectl-and-helm-clients-directly-on-a-host.rst
View File

@@ -58,7 +58,7 @@ You will need the following information from your |prod| administrator:
% sudo apt-get update % sudo apt-get update
% sudo apt-get install -y kubectl % 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. #. Set up the local configuration and context.

8
doc/source/usertasks/kubernetes/usertask-using-container-backed-remote-clis-and-clients.rst
View File

@@ -118,10 +118,10 @@ Helm
Do the following to use helm. Do the following to use helm.
.. xreflink .. note:: .. note::
For non-admin users, additional configuration is required first as For non-admin users, additional configuration is required first as
discussed in |sec-doc|: :ref:`Configuring Remote Helm Client for discussed in |sec-doc|: :ref:`Configuring Remote Helm Client for
Non-Admin Users <configuring-remote-helm-client-for-non-admin-users>`. Non-Admin Users <configure-remote-helm-client-for-non-admin-users>`.
.. note:: .. note::
When using helm, any command that requires access to a helm repository When using helm, any command that requires access to a helm repository