starlingx/docs
Code Issues Proposed changes

Merge "Update Security"

Browse Source
This commit is contained in:
Zuul 2021-04-06 16:05:18 +00:00 committed by Gerrit Code Review
commit f52ba83266
59 changed files with 944 additions and 668 deletions
Show Stats 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
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
|CA| certificate\(s\) to trust. The certificate\(s\) must be in |PEM| format
@ -62,14 +62,14 @@ From the command line, run the :command:`certificate-install` command.
.. code-block:: none
~(keystone_admin)$ system certificate-install -m ssl_ca <trusted-ca-bundle-pem-file>
~(keystone_admin)]$ system certificate-install -m ssl_ca <trusted-ca-bundle-pem-file>
For example:
.. code-block:: none
~(keystone_admin)$ system certificate-install -m ssl_ca external-registry-ca-crt.pem
~(keystone_admin)]$ system certificate-install -m ssl_ca external-registry-ca-crt.pem
WARNING: For security reasons, the original certificate,
containing the private key, will be removed,
once the private key is processed.
@ -100,7 +100,7 @@ running the following command:
.. code-block:: none
~(keystone_admin)$ system certificate-list
~(keystone_admin)]$ system certificate-list
where, all entries with certtype = ssl\_ca are trusted |CA| certificates.
@ -109,7 +109,7 @@ running the following command:
.. code-block:: none
~(keystone_admin)$ system certificate-uninstall -m ssl_ca <UUID>
~(keystone_admin)]$ system certificate-uninstall -m ssl_ca <UUID>
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
|org| builds and are authenticated before they are loaded on a system via
|prod| REST APIs, CLIs or GUI.
.. xbooklink For more information on patches, see |updates-doc|: :ref:`Software Updates
<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
~(keystone_admin)$ system service-parameter-modify horizon auth \
~(keystone_admin)]$ system service-parameter-modify horizon auth \
lockout_seconds=<duration>
where <duration> is the time in seconds.
@ -42,7 +42,7 @@ using the following CLI command:
.. code-block:: none
~(keystone_admin)$ system service-parameter-modify horizon auth \
~(keystone_admin)]$ system service-parameter-modify horizon auth \
lockout_retries=<attempts>
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
~(keystone_admin)$ system service-parameter-apply horizon
~(keystone_admin)]$ system service-parameter-apply horizon
Allow about 30 seconds after applying the changes for the Web service to
restart.

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

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
~(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.
.. 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
~(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>
@ -67,7 +67,7 @@ you can do so at any time using service parameters.
.. code-block:: none
~(keystone_admin)$ system service-parameter-apply kubernetes
~(keystone_admin)]$ system service-parameter-apply kubernetes
For more information on |OIDC| Authentication for subclouds, see
:ref:`Centralized OIDC Authentication Setup for Distributed Cloud

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
% 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
and that :command:`kubectl` commands are functioning properly.
@ -80,7 +92,7 @@ For example:
.. code-block:: none
~(keystone_admin)$ system host-list
~(keystone_admin)]$ system host-list
+----+--------------+-------------+----------------+-------------+--------------+
| id | hostname | personality | administrative | operational | availability |
+----+--------------+-------------+----------------+-------------+--------------+
@ -104,7 +116,7 @@ For example:
.. code-block:: none
~(keystone_admin)$ fm alarm-list
~(keystone_admin)]$ fm alarm-list
+-------+---------------+---------------------+----------+---------------+
| Alarm | Reason Text | Entity ID | Severity | Time Stamp |
@ -125,10 +137,10 @@ For example:
.. code-block:: none
~(keystone_admin)$ kubectl get nodes
~(keystone_admin)]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
controller-0 Ready master 5d19h v1.13.5
~(keystone_admin)$ kubectl get pods
~(keystone_admin)]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
dashboard-kubernetes-dashboard-7749d97f95-bzp5w 1/1 Running 0 3d18h

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

@ -82,22 +82,22 @@ and uploaded by default.
.. code-block:: none
~(keystone_admin)$ kubectl create secret tls local-dex.tls --cert=ssl/dex-cert.pem --key=ssl/dex-key.pem -n kube-system
~(keystone_admin)]$ kubectl create secret tls local-dex.tls --cert=ssl/dex-cert.pem --key=ssl/dex-key.pem -n kube-system
~(keystone_admin)$ kubectl create secret generic dex-client-secret --from-file=/home/sysadmin/ssl/dex-ca.pem -n kube-system
~(keystone_admin)]$ kubectl create secret generic dex-client-secret --from-file=/home/sysadmin/ssl/dex-ca.pem -n kube-system
Create the secret **wadcert** with the |CA|'s certificate that signed
the Active Directory's certificate using the following command:
.. code-block:: none
~(keystone_admin)$ kubectl create secret generic wadcert --from-file=ssl/AD_CA.cer -n kube-system
~(keystone_admin)]$ kubectl create secret generic wadcert --from-file=ssl/AD_CA.cer -n kube-system
#. Specify user overrides for **oidc-auth-apps** application, by using the following command:
.. code-block:: none
~(keystone_admin)$ system helm-override-update oidc-auth-apps dex kube-system --values /home/sysadmin/dex-overrides.yaml
~(keystone_admin)]$ system helm-override-update oidc-auth-apps dex kube-system --values /home/sysadmin/dex-overrides.yaml
The dex-overrides.yaml file contains the desired dex helm chart overrides
\(that is, the LDAP connector configuration for the Active Directory
@ -119,9 +119,44 @@ and uploaded by default.
Directory service login information \(that is, bindDN, and bindPW\), and
example :command:`userSearch`, and :command:`groupSearch` clauses.
\(Optional\) There is a default secret in the dex configuration for
**staticClients**. You can change this using helm overrides. For example,
to change the secret, first run the following command to see the default
settings. In this example, 10.10.10.2 is the |prod-long| |OAM| floating IP
address.
.. code-block:: none
~(keystone_admin)]$ system helm-override-show oidc-auth-apps dex kube-system
config:
staticClients:
- id: stx-oidc-client-app
name: STX OIDC Client app
redirectURIs: ['https://10.10.10.2:30555/callback']
secret: St8rlingX
Change the secret from the output and copy the entire configuration section
shown above in to your dex overrides file shown in the example below.
.. note::
Do NOT forget to include the id, name, and redirectURIs parameters.
.. note::
There is an internal **client\_secret** that is used between the
oidc-client container and the dex container. It is recommended that you
configure a unique, more secure **client\_secret** by specifying the
value in the dex overrides file, as shown in the example below.
.. code-block:: none
config:
staticClients:
- id: stx-oidc-client-app
name: STX OIDC Client app
redirectURIs: ['<OAM floating IP address>/callback']
secret: BetterSecret
client_secret: BetterSecret
expiry:
idTokens: "10h"
connectors:
@ -134,7 +169,7 @@ and uploaded by default.
insecureNoSSL: false
insecureSkipVerify: false
bindDN: cn=Administrator,cn=Users,dc=cumulus,dc=wrs,dc=com
bindPW: Li69nux*
bindPW: [<password>]
usernamePrompt: Username
userSearch:
baseDN: ou=Users,ou=Titanium,dc=cumulus,dc=wrs,dc=com
@ -155,7 +190,7 @@ and uploaded by default.
secretName: wadcert
extraVolumeMounts:
- name: certdir
mountPath: /etc/ssl/certs/adcer
mountPath: /etc/ssl/certs/adcert
If more than one Windows Active Directory service is required for
authenticating the different users of the |prod|, multiple '**ldap**'
@ -170,11 +205,35 @@ and uploaded by default.
Whenever you use multiple '**ldap**' type connectors, ensure you use
unique '**name:**' and '**id:**' parameters for each connector.
#. An override in the secrets in the dex helm chart must be accompanied by an
override in the oidc-client helm chart.
The following override is sufficient for changing the secret in the
/home/sysadmin/oidc-client-overrides.yaml file.
.. code-block:: none
config:
client_secret: BetterSecret
Apply the oidc-client overrides using the following command:
.. code-block:: none
~(keystone_admin)]$ system helm-override-update oidc-auth-apps oidc-client kube-system --values /home/sysadmin/oidc-client-overrides.yaml
.. note::
If you need to manually override the secrets, the client\_secret in the
oidc-client overrides must match the staticClients secret and
client\_secret in the dex overrides, otherwise the oidc-auth |CLI|
client will not function.
#. Use the :command:`system application-apply` command to apply the
configuration:
.. code-block:: none
~(keystone_admin)$ system application-apply oidc-auth-apps
~(keystone_admin)]$ system application-apply oidc-auth-apps

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

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

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

@ -6,24 +6,23 @@
Create LDAP Linux Accounts
==========================
|prod| includes a script for creating LDAP Linux accounts with built-in
Keystone user support.
|prod| includes a script for creating |LDAP| Linux accounts.
.. rubric:: |context|
The :command:`ldapusersetup` command provides an interactive method for
setting up LDAP Linux user accounts with access to StarlingX commands. You
can assign a limited shell or a bash shell.
.. note::
For security reasons, it is recommended that ONLY admin level users be
allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
strictly use remote |CLIs| or remote web GUIs.
Users have the option of providing Keystone credentials at login, and can
establish or change Keystone credentials at any time during a session.
Keystone credentials persist for the duration of the session.
The :command:`ldapusersetup` command provides an interactive method for setting
up |LDAP| Linux user accounts.
Centralized management is implemented using two LDAP servers, one running on
each controller node. LDAP server synchronization is automatic using the
native LDAP content synchronization protocol.
Centralized management is implemented using two |LDAP| servers, one running on
each controller node. |LDAP| server synchronization is automatic using the
native |LDAP| content synchronization protocol.
A set of LDAP commands is available to operate on LDAP user accounts. The
A set of |LDAP| commands is available to operate on |LDAP| user accounts. The
commands are installed in the directory /usr/local/sbin, and are available to
any user account in the sudoers list. Included commands are
:command:`lsldap`, :command:`ldapadduser`, :command:`ldapdeleteuser`, and
@ -43,18 +42,6 @@ as illustrated below.
For convenience, identify the user's Keystone account user name in |prod-long|.
.. note::
There is an M:M relationship between a Keystone user account and a user
Linux account. That is, the same Keystone user account may be used across
multiple Linux accounts. For example, the Keystone user **tenant user**
may be used by several Linux users, such as Kam, Greg, and Jim.
Conversely, contingent on the policy of the organization, 3 Keystone
cloud users \(Kam, Greg, and Jim\), may be used by a single Linux
account: **operator**. That is, Kam logs into |prod| with the
**operator** account, and sources Kam's Keystone user account. Jim does
the same and logs into |prod| with the **operator** account, but sources
Jim's Keystone user account.
.. rubric:: |proc|
#. Log in as **sysadmin**, and start the :command:`ldapusersetup` script.
@ -70,39 +57,15 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
.. code-block:: none
Enter username to add to LDAP:
For convenience, use the same name as the one assigned for the user's
Keystone account. \(This example uses **user1**\). When the LDAP user
logs in and establishes Keystone credentials, the LDAP user name is
offered as the default Keystone user name.
Enter username to add to |LDAP|:
.. code-block:: none
Successfully added user user1 to LDAP
Successfully added user user1 to |LDAP|
Successfully set password for user user1
#. Specify whether to provide a limited shell or a bash shell.
.. code-block:: none
Select Login Shell option # [2]:
1) Bash
2) Lshell
To provide a limited shell with access to the StarlingX CLI only,
specify the Lshell option.
If you select Bash, you are offered the option to add the user to the
sudoer list:
.. code-block:: none
Add user1 to sudoer list? (yes/No):
#. Specify a secondary user group for this LDAP user.
#. Specify a secondary user group for this |LDAP| user.
.. code-block:: none
@ -116,7 +79,7 @@ For convenience, identify the user's Keystone account user name in |prod-long|.
.. code-block:: none
Successfully modified user entry uid=ldapuser1, ou=People, dc=cgcs, dc=local in LDAP
Successfully modified user entry uid=ldapuser1, ou=People, dc=cgcs, dc=local in |LDAP|
Updating password expiry to 90 days
#. Change the warning period before the password expires.
@ -139,7 +102,7 @@ On completion of the script, the command prompt is displayed.
.. rubric:: |result|
The LDAP account is created. For information about the user login process,
see :ref:`Establish Keystone Credentials from a Linux Account
<establish-keystone-credentials-from-a-linux-account>`.
The |LDAP| account is created. For information about the user login process, see
ref:`For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account
Login <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
~(keystone_admin)$ system service-parameter-list
~(keystone_admin)]$ system service-parameter-list
#. Delete each parameter.
.. code-block:: none
~(keystone_admin)$ system service-parameter-delete <UUID>
~(keystone_admin)]$ system service-parameter-delete <UUID>
#. Apply the changes.
.. code-block:: none
~(keystone_admin)$ system service-parameter-apply kubernetes
~(keystone_admin)]$ system service-parameter-apply kubernetes
#. Uninstall oidc-auth-apps.
.. code-block:: none
~(keystone_admin)$ system application-remove oidc-auth-apps
~(keystone_admin)]$ system application-remove oidc-auth-apps
#. Clear the helm-override configuration.
.. code-block:: none
~(keystone_admin)$ system helm-override-update oidc-auth-apps dex kube-system --reset-values
~(keystone_admin)$ system helm-override-show oidc-auth-apps dex kube-system
~(keystone_admin)]$ system helm-override-update oidc-auth-apps dex kube-system --reset-values
~(keystone_admin)]$ system helm-override-show oidc-auth-apps dex kube-system
~(keystone_admin)$ system helm-override-update oidc-auth-apps oidc-client kube-system --reset-values
~(keystone_admin)$ system helm-override-show oidc-auth-apps oidc-client kube-system
~(keystone_admin)]$ system helm-override-update oidc-auth-apps oidc-client kube-system --reset-values
~(keystone_admin)]$ system helm-override-show oidc-auth-apps oidc-client kube-system
#. Remove secrets that contain certificate data.
.. code-block:: none
~(keystone_admin)$ kubectl delete secret local-dex.tls -n kube-system
~(keystone_admin)$ kubectl delete secret dex-client-secret -n kube-system
~(keystone_admin)$ kubectl delete secret wadcert -n kube-system
~(keystone_admin)]$ kubectl delete secret local-dex.tls -n kube-system
~(keystone_admin)]$ kubectl delete secret dex-client-secret -n kube-system
~(keystone_admin)]$ kubectl delete secret wadcert -n kube-system
#. Remove any |RBAC| RoleBindings added for |OIDC| users and/or groups.

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
~(keystone_admin)$ system service-parameter-delete <uuid>
~(keystone_admin)]$ system service-parameter-delete <uuid>
#. Apply the Kubernetes system parameters.
.. 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
~(keystone_admin)$ system modify --https_enabled true
~(keystone_admin)]$ system modify --https_enabled true
- To disable HTTPS for StarlingX REST and Web Server endpoints:
.. code-block:: none
~(keystone_admin)$ system modify --https_enabled false
~(keystone_admin)]$ system modify --https_enabled false
- Use the following command to display HTTPS settings:

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
~(keystone_admin)$ system service-parameter-add kubernetes kube_apiserver admission_plugins=PodSecurityPolicy
~(keystone_admin)]$ system service-parameter-add kubernetes kube_apiserver admission_plugins=PodSecurityPolicy
#. Apply the Kubernetes system parameters.
.. code-block:: none
~(keystone_admin)$ system service-parameter-apply kubernetes
~(keystone_admin)]$ system service-parameter-apply kubernetes
#. View the automatically added pod security policies.

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

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
.. _establish-keystone-credentials-from-a-linux-account:
===================================================
Establish Keystone Credentials from a Linux Account
===================================================
===============================================================================
For StarlingX and Platform OpenStack CLIs from a Local LDAP Linux Account Login
===============================================================================
The preferred method for establishing Keystone credentials is to log in to
an LDAP account created using :command:`ldapusersetup`.
You can establish Keystone credentials for executing StarlingX and Platform
OpenStack |CLIs| for a local |LDAP| user, if required; this is not setup by
default.
.. contents::
:local:
@ -19,110 +20,43 @@ For more information about :command:`ldapusersetup`, see :ref:`Create LDAP
Linux Accounts <create-ldap-linux-accounts>`.
User accounts created using :command:`ldapusersetup` have access to the
Keystone CLI as part of the shell. To list the available commands, type
**?** at the command line:
StarlingX |CLIs| \(system, fm, sw-patch, dcmanager, etc.\) and the platform
'OpenStack' CLI as part of the shell.
.. code-block:: none
.. rubric:: |prereq|
user1@controller-0:~$ ?
.. _establish-keystone-credentials-from-a-linux-account-ul-qyv-fzm-ynb:
awk echo history ls pwd source cat clear
env grep keystone lsudo rm system cd cp
exit ll man openstack scp vim cut export
help lpath env passwd sftp kubectl helm
- You must have a platform Keystone user account. For more information about
creating Keystone users, managing keystone projects, users and roles, see
`https://docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html
<https://docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html>`__.
When a user logs in to an account of this type, they are prompted to store
Keystone credentials for the duration of the session:
- It is recommended to use the same username for both your local |LDAP| user
and your Keystone user.
.. code-block:: none
.. rubric:: |context|
Pre-store Keystone user credentials for this session? (y/N):y
You can establish Keystone credentials, in order to use the StarlingX and
Platform OpenStack |CLIs|, using one of the following methods:
This invokes a script to obtain the credentials. The user can invoke the
same script at any time during the session as follows:
.. rubric:: |proc|
.. code-block:: none
.. _estabilish-keystone-credentials-from-a-linux-account-steps-hjs-dwm-ynb:
user1@controller-0:~$ source /home/sysadmin/lshell_env_setup
#. \(Method 1\) When you have logged into the Horizon Web interface with your
Keystone user credentials, download an OpenStack RC file \(openrc.sh\), and
use it to source the required environment within your local LDAP user shell
. For more information on downloading your OpenStack RC file from Horizon,
see, `http://docs.openstack.org <http://docs.openstack.org/>`__.
Any Keystone credentials created by the script persist for the duration of
the session. This includes credentials added by previous invocations of the
script in the same session.
#. \(Method 2\) Add the required environment variables manually into a
wrcprc.sh file and use this to source the required environment within your
local |LDAP| user shell.
.. _establish-keystone-credentials-from-a-linux-account-section-N10079-N10020-N10001:
-------------------------------
The Keystone Credentials Script
-------------------------------
The Keystone credentials script offers the LDAP user name as the default
Keystone user name:
.. code-block:: none
Enter Keystone username [user1]:
.. code-block:: none
Enter Keystone user domain name:
It requires the name of the tenant for which the user requires access:
.. code-block:: none
Enter Project name:tenant1
.. note::
The Keystone user must be a member of a Keystone tenant. This is
configured using Keystone.
.. code-block:: none
Enter Project domain name:
It also requires the Keystone user password:
.. code-block:: none
Enter Keystone password:
When the script is run during login, it sets the default **Keystone Region
Name** and **Keystone Authentication URL**.
.. code-block:: none
Selecting default Keystone Region Name: RegionOne
Selecting default Keystone Authentication URL: http://192.168.204.2:5000/v2.0/
To re-configure your environment run "source ~/lshell_env_setup" in your shell
Keystone credentials preloaded!
If the script is run from the shell after login, it provides an option to
change the **Keystone Region Name** and **Keystone Authentication URL**.
.. _establishing-keystone-credentials-from-a-linux-account-section-N100B5-N10020-N10001:
---------------------------------------------------------
Alternative Methods for Establishing Keystone Credentials
---------------------------------------------------------
You can also establish Keystone credentials using the following methods:
.. _establish-keystone-credentials-from-a-linux-account-ul-scj-rch-t5:
- Download an OpenStack RC file \(openrc.sh\) from the Horizon Web
interface, and use it to source the required environment. For more
information, refer to `http://docs.openstack.org
<http://docs.openstack.org>`__.
.. note::
Only users with bash shell can source the required environment. This
does not apply to users with limited shell.
- Add the required environment variables manually:
For security and reliability, add all the variables.
**OS\_USERNAME**
the Keystone user name
@ -149,20 +83,4 @@ You can also establish Keystone credentials using the following methods:
the interface
**OS\_REGION\_NAME**
the Keystone Region Name
For security and reliability, add all of the variables.
- Provide credentials as command-line options.
.. code-block:: none
user1@controller-0:~$ system --os-username admin --os-password seeCaution host-list
.. caution::
|org| does not recommend using the command-line option to provide
Keystone credentials. It creates a security risk, because the
supplied credentials are visible in the command-line history.
the Keystone Region Name

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

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

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

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

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
~(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.
@ -36,19 +36,19 @@ You can install Portieris on |prod| from the command line.
.. code-block:: none
~(keystone_admin)$ echo 'caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURYVENDQWtXZ0F3SUJBZ0lKQUpjVHBXcTk4SWNSTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4Q3pBSkJnTlYKQkFZVEFrRlZNUk13RVFZRFZRUUlEQXBUYjIxbExWTjBZWFJsTVNFd0h3WURWUVFLREJoSmJuUmxjbTVsZENCWAphV1JuYVhSeklGQjBlU0JNZEdRd0hoY05NVGd3T0RFMk1qQXlPREl3V2hjTk1qRXdOakExTWpBeU9ESXdXakJGCk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkRYwWlRFaE1COEdBMVVFQ2d3WVNXNTAKWlhKdVpYUWdWMmxrWjJsMGN5QlFkSGtnVEhSa01JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQgpDZ0tDQVFFQXV4YXJMaVdwMDVnbG5kTWRsL1o3QmhySDFPTFNTVTcwcm9mV3duTmNQS3hsOURmVVNWVTZMTDJnClppUTFVZnA4TzFlVTJ4NitPYUxxekRuc2xpWjIxdzNXaHRiOGp2NmRFakdPdTg3eGlWWDBuSDBmSjF3cHFBR0UKRkVXekxVR2dJM29aUDBzME1Sbm1xVDA4VWZ6S0hCaFgvekNvNHMyVm9NcWxRNyt0Qjc2dTA3V3NKYQ0RFlQVwprR2tFVmRMSk4rWWcwK0pLaisvVU9kbE5WNDB2OE1ocEhkbWhzY1QyakI3WSszT0QzeUNxZ1RjRzVDSDQvK3J6CmR4Qjk3dEpMM2NWSkRQWTVNQi9XNFdId2NKRkwzN1p1M0dVdmhmVGF3NVE0dS85cTFkczgrVGFYajdLbWUxSzcKQnYyMTZ5dTZiN3M1ckpHU2lEZ0p1TWFNcm5YajFRSURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVyQndhbTAreApydUMvY3Vpbkp1RlM4Y1ZibjBBd0h3WURWUjBqQkJnd0ZvQVVyQndhbTAreHJ1Qy9jdWluSnVGUzhjVmJuMEF3CkRBWURWUjBUQFVd0F3RUIvekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZzJ5aEFNazVJUlRvOWZLc1IvMXkKMXJ5NzdSWU5KN1R2dTB0clltRElBMVRaanFtanlncFFiSmlGb0FPa255eHYveURLU0x6TXFNU2JIb0I1K1BhSQpnTERub0F6SnYxbzg3OEpkVllURjIyS2RUTU5wNWtITXVGMnpSTFFxc2lvenJQSUpWMDlVb2VHeHpPQ1pkYzZBCnpUblpCSy9DVTlRcnhVdzhIeDV6SEFVcHdVcGxONUE4MVROUmlMYVFVTXB5dzQ4Y08wNFcyOWY1aFA2aGMwVDMKSDJpU212OWY2K3Q5TjBvTTFuWVh1blgwWNJZll1aERmQy83c3N3eDhWcW5uTlNMN0lkQkhodGxhRHJGRXBzdQpGZzZOODBCbGlDclJiN2FPcUk4TWNjdzlCZW9UUk9uVGxVUU5RQkEzTjAyajJvTlhYL2loVHQvZkhNYlZGUFRQCi9nPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' > caCert.yaml
~(keystone_admin)]$ echo 'caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURYVENDQWtXZ0F3SUJBZ0lKQUpjVHBXcTk4SWNSTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4Q3pBSkJnTlYKQkFZVEFrRlZNUk13RVFZRFZRUUlEQXBUYjIxbExWTjBZWFJsTVNFd0h3WURWUVFLREJoSmJuUmxjbTVsZENCWAphV1JuYVhSeklGQjBlU0JNZEdRd0hoY05NVGd3T0RFMk1qQXlPREl3V2hjTk1qRXdOakExTWpBeU9ESXdXakJGCk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkRYwWlRFaE1COEdBMVVFQ2d3WVNXNTAKWlhKdVpYUWdWMmxrWjJsMGN5QlFkSGtnVEhSa01JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQgpDZ0tDQVFFQXV4YXJMaVdwMDVnbG5kTWRsL1o3QmhySDFPTFNTVTcwcm9mV3duTmNQS3hsOURmVVNWVTZMTDJnClppUTFVZnA4TzFlVTJ4NitPYUxxekRuc2xpWjIxdzNXaHRiOGp2NmRFakdPdTg3eGlWWDBuSDBmSjF3cHFBR0UKRkVXekxVR2dJM29aUDBzME1Sbm1xVDA4VWZ6S0hCaFgvekNvNHMyVm9NcWxRNyt0Qjc2dTA3V3NKYQ0RFlQVwprR2tFVmRMSk4rWWcwK0pLaisvVU9kbE5WNDB2OE1ocEhkbWhzY1QyakI3WSszT0QzeUNxZ1RjRzVDSDQvK3J6CmR4Qjk3dEpMM2NWSkRQWTVNQi9XNFdId2NKRkwzN1p1M0dVdmhmVGF3NVE0dS85cTFkczgrVGFYajdLbWUxSzcKQnYyMTZ5dTZiN3M1ckpHU2lEZ0p1TWFNcm5YajFRSURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVyQndhbTAreApydUMvY3Vpbkp1RlM4Y1ZibjBBd0h3WURWUjBqQkJnd0ZvQVVyQndhbTAreHJ1Qy9jdWluSnVGUzhjVmJuMEF3CkRBWURWUjBUQFVd0F3RUIvekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZzJ5aEFNazVJUlRvOWZLc1IvMXkKMXJ5NzdSWU5KN1R2dTB0clltRElBMVRaanFtanlncFFiSmlGb0FPa255eHYveURLU0x6TXFNU2JIb0I1K1BhSQpnTERub0F6SnYxbzg3OEpkVllURjIyS2RUTU5wNWtITXVGMnpSTFFxc2lvenJQSUpWMDlVb2VHeHpPQ1pkYzZBCnpUblpCSy9DVTlRcnhVdzhIeDV6SEFVcHdVcGxONUE4MVROUmlMYVFVTXB5dzQ4Y08wNFcyOWY1aFA2aGMwVDMKSDJpU212OWY2K3Q5TjBvTTFuWVh1blgwWNJZll1aERmQy83c3N3eDhWcW5uTlNMN0lkQkhodGxhRHJGRXBzdQpGZzZOODBCbGlDclJiN2FPcUk4TWNjdzlCZW9UUk9uVGxVUU5RQkEzTjAyajJvTlhYL2loVHQvZkhNYlZGUFRQCi9nPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' > caCert.yaml
#. Apply the override file.
.. code-block:: none
~(keystone_admin)$ system helm-override-update portieris portieris-certs portieris --values caCert.yaml
~(keystone_admin)]$ system helm-override-update portieris portieris-certs portieris --values caCert.yaml
#. Apply the application.
.. code-block:: none
~(keystone_admin)$ system application-apply portieris
~(keystone_admin)]$ system application-apply portieris

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

@ -29,7 +29,7 @@ Dashboard.
.. code-block:: none
~(keystone_admin)$ kubectl create namespace kubernetes-dashboard
~(keystone_admin)]$ kubectl create namespace kubernetes-dashboard
#. Create a certificate for use by the Kubernetes Dashboard.
@ -43,20 +43,20 @@ Dashboard.
.. code-block:: none
~(keystone_admin)$ cd /home/sysadmin
~(keystone_admin)$ mkdir -p /home/sysadmin/kube/dashboard/certs
~(keystone_admin)]$ cd /home/sysadmin
~(keystone_admin)]$ mkdir -p /home/sysadmin/kube/dashboard/certs
#. Create the certificate.
.. code-block:: none
~(keystone_admin)$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /home/sysadmin/kube/dashboard/certs/dashboard.key -out /home/sysadmin/kube/dashboard/certs/dashboard.crt -subj "/CN=<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:
**<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.
@ -73,7 +73,7 @@ Dashboard.
.. code-block:: none
~(keystone_admin)$ wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
~(keystone_admin)]$ wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
#. Edit the file.
@ -98,18 +98,18 @@ Dashboard.
.. code-block:: none
~(keystone_admin)$ kubectl apply -f recommended.yaml
~(keystone_admin)]$ kubectl apply -f recommended.yaml
#. Patch the kubernetes dashboard service to type=NodePort and port=30000.
.. code-block:: none
~(keystone_admin)$ kubectl patch service kubernetes-dashboard -n kubernetes-dashboard -p '{"spec":{"type":"NodePort","ports":[{"port":443, "nodePort":30000}]}}'
~(keystone_admin)]$ kubectl patch service kubernetes-dashboard -n kubernetes-dashboard -p '{"spec":{"type":"NodePort","ports":[{"port":443, "nodePort":30000}]}}'
#. Test the Kubernetes Dashboard deployment.
The Kubernetes Dashboard is listening at port 30000 on the machine
defined above for |prod| cluster's OAM floating IP.
defined above for |prod| cluster's |OAM| floating IP.
#. Access the dashboard at https://<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|
Obtain a Root |CA|-signed certificate and key from a trusted Root |CA|.
Refer to the documentation for the external Root |CA| that you are using,
on how to create public certificate and private key pairs, signed by a Root
|CA|, for HTTPS.
Obtain an intermediate or Root |CA|-signed certificate and key from a trusted
intermediate or Root |CA|. Refer to the documentation for the external
Intermediate or Root |CA| that you are using, on how to create public
certificate and private key pairs, signed by intermediate or a Root |CA|, for
HTTPS.
.. xbooklink
For lab purposes, see :ref:`Locally Creating Certificates
<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,
and copy the file to the controller host.
@ -34,13 +36,13 @@ and copy the file to the controller host.
.. code-block:: none
~(keystone_admin)$ system certificate-install <pathTocertificateAndKey>
~(keystone_admin)]$ system certificate-install -m ssl <pathTocertificateAndKey>
where:
**<pathTocertificateAndKey>**
is the path to the file containing both the Root |CA|-signed certificate
and private key to install.
is the path to the file containing both the intermediate or Root
|CA|-signed certificate and private key to install.

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.
For information on internal networks, see the :ref:`StarlingX Planning Guide
<overview-of-starlingx-planning>`. The network should be configured as a
private network visible to only the hosts on the cluster. Proper switch
configuration is required to achieve the isolation.
<overview-of-starlingx-planning>` should be configured as a private network
visible to only the hosts on the cluster. Proper switch configuration is
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
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
<k8s\_root\_ca\_key>, as part of the installation procedure to specify the
certificate and key for the Kubernetes root |CA|.
@ -74,6 +86,8 @@ associated with the |OAM| floating IP address should be added.
Make the K8S Root |CA| certificate available to any remote server wanting to
connect remotely to the |prod|'s Kubernetes API, e.g. through kubectl or helm.
This Kubernetes Root CA certificate should be configured as a trusted |CA| on
the remote server.
See the step :ref:`2.b
<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 Linux user accounts should NOT be configured, only use local LDAP
accounts for internal system purposes that would usually not be created by
an end-user.
- Local Linux user accounts should NOT be configured, only use local |LDAP|
accounts for internal system purposes that would usually not be created by
an end-user.
Password changes are not enforced automatically on the first login, and
they are not propagated by the system \(only for 'sysadmin'\).
- Password changes are not enforced automatically on the first login, and
they are not propagated by the system \(only for 'sysadmin'\).
.. note::
If the administrator wants to provision additional access to the
system, it is better to configure local LDAP Linux accounts.
- **If the administrator wants to provision additional access to the system, it is better to configure local LDAP Linux accounts.**
- LDAP accounts are centrally managed; changes made on any host are
- |LDAP| accounts are centrally managed; changes made on any host are
propagated automatically to all hosts on the cluster.
- LDAP user accounts behave as any local user account. They can be added
- |LDAP| user accounts behave as any local user account. They can be added
to the sudoers list and can acquire OpenStack administration credentials.
- The initial password must be changed immediately upon the first login.
@ -42,11 +39,10 @@ they are not propagated by the system \(only for 'sysadmin'\).
of the target host.
.. note::
For security reasons, it is recommended that ONLY admin level users
be allowed to SSH to the nodes of |prod|. Non-admin level users
should strictly use remote CLIs or remote web GUIs.
For security reasons, it is recommended that ONLY admin level users be
allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
strictly use remote |CLIs| or remote web GUIs.
Operational complexity:
@ -54,14 +50,14 @@ Operational complexity:
- Passwords aging is automatically configured.
- LDAP user accounts \(operator, admin\) are available by default on
- |LDAP| user accounts \(operator, admin\) are available by default on
newly deployed hosts. For increased security, the admin and operator
accounts must be used from the console ports of the hosts; no SSH access is
allowed.
accounts must be used from the console ports of the hosts; no |SSH| access
is allowed.
- |prod| includes a script for creating LDAP Linux accounts with built-in
- |prod| includes a script for creating |LDAP| Linux accounts with built-in
Keystone user support. It provides an interactive method for setting up
LDAP Linux user accounts with access to OpenStack commands. You can assign
a limited shell or a bash shell.
|LDAP| Linux user accounts with access to OpenStack commands. You can
assign a limited shell or a bash shell.

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
strictly use remote CLIs or remote web GUIs.
Apart from being centrally managed, LDAP user accounts behave as any local
user account. They can be added to the sudoers list, and can acquire
Keystone administration credentials when executing on the active controller.
Apart from being centrally managed, LDAP user accounts behave as any local user
account. They can be added to the sudoers list, and can acquire Keystone
administration credentials, Kubernetes kubectl, and helm administrative
commands as the Kubernetes admin user, when executing on the active controller.
LDAP user accounts share the following set of attributes:
@ -50,6 +51,12 @@ LDAP user accounts share the following set of attributes:
and are local to that host.
.. _local-ldap-linux-user-accounts-section-kts-bvh-ynb:
--------------------------
Default LDAP User Accounts
--------------------------
The following LDAP user accounts are available by default on newly deployed
hosts, regardless of their personality:
@ -57,9 +64,9 @@ hosts, regardless of their personality:
A cloud administrative account, comparable to the default **admin**
account used in the web management interface.
This user account operates on a restricted Linux shell, with very
limited access to native Linux commands. However, the shell is
preconfigured to have administrative access to StarlingX commands.
This user account has access to all native Linux commands not requiring
root or sudo privileges, and it's shell is preconfigured to have
administrative access to StarlingX commands.
**admin**
A host administrative account. It has access to all native Linux
@ -80,4 +87,6 @@ from the console ports of the hosts; no SSH access is allowed.
**operator** account enables access to the cloud deployment only, without
giving unabated sudo access to the entire system.
.. seealso::
:ref:`Creating LDAP Linux Accounts <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'
==================================
This is a local, per-host, sudo-enabled account created automatically when
a new host is provisioned.
This is a local, per-host, sudo-enabled account created automatically when a
new host is provisioned.
This Linux user account is used by the system administrator as it has
extended privileges.
This Linux user account is used by the system administrator as it has extended
privileges.
.. _local-linux-account-for-sysadmin-ul-zgk-1wf-mmb:
@ -21,8 +21,7 @@ extended privileges.
- After five consecutive unsuccessful login attempts, further attempts
are blocked for about five minutes.
Operational complexity: None.
The above security hardening features are set by default \(see :ref:`System
Account Password Rules <system-account-password-rules>` for password rules\).
Operational complexity: None. The above security hardening features are set by
default \(see :ref:`System Account Password Rules
<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>`_
_ for details on managing Keystone projects, users, and roles.
.. note::
All Kubernetes accounts are subject to system password rules. For
complete details on password rules, see :ref:`System Account Password
Rules <starlingx-system-accounts-system-account-password-rules>`.
All Kubernetes accounts are subject to system password rules. For complete
details on password rules, see :ref:`System Account Password Rules
<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:
If using the FIXME: REMOVE, when changing the Keystone 'admin' user
password, you must:
#. If the **deployment-config.yaml** file has been moved off-box for security
reasons, upload the file back to the system to be updated.
#. Update the password in the 'system-endpoint' secret in the FIXME:
REMOVE's deployment-config.yaml file, with the new Keystone 'admin'
user password.
.. warning::
The **deployment-config.yaml** file includes sensitive information
\(including system credentials and passwords\). For increased security,
it is recommended to store the **deployment-config.yaml** in a safe
location off-box. Upload the file to the system only when it is
required \(during initial configuration, and when reapplying an updated
configuration\).
Make this change to the OS\_PASSWORD value. It must be base64 encoded. For example:
#. Update the password in the 'system-endpoint' secret in the 's
deployment-config.yaml file, with the new keystone 'admin' user password.
Make this change to the OS\_PASSWORD value. It must be base64 encoded. For
example:
.. code-block:: none
@ -37,4 +46,5 @@ password, you must:
kubectl apply -f deployment-config.yaml
#. \(Optional\) For security reasons, copy the updated
**deployment-config.yaml** file off-box and delete it from the system.

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
~(keystone_admin)$ TOKEN=<ID_token_string>
~(keystone_admin)$ kubectl config set-credentials testuser --token $TOKEN
~(keystone_admin)]$ TOKEN=<ID_token_string>
~(keystone_admin)]$ kubectl config set-credentials testuser --token $TOKEN
#. Switch to the Kubernetes context for the user, by using the following
command, for example:
.. code-block:: none
~(keystone_admin)$ kubectl config use-context testuser@mywrcpcluster
~(keystone_admin)]$ kubectl config use-context testuser@mywrcpcluster
#. Run the following command to test that the authentication token
validates correctly:
.. code-block:: none
~(keystone_admin)$ kubectl get pods --all-namespaces
~(keystone_admin)]$ kubectl get pods --all-namespaces

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
~(keystone_admin)$ oidc-auth -c <ip> -u <username>
~(keystone_admin)]$ oidc-auth -c <ip> -u <username>
For example,
.. code-block:: none
~(keystone_admin)$ oidc-auth -c <OAM_ip_address> -u testuser
~(keystone_admin)]$ oidc-auth -c <OAM_ip_address> -u testuser
Password:
Login succeeded.
Updating kubectl config ...
@ -75,7 +75,7 @@ credential for the user in the **kubectl** config file.
.. code-block:: none
~(keystone_admin)$ oidc-auth -b <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
.. _overview-of-system-accounts:
=====================================
Overview of StarlingX System Accounts
=====================================
==================
Linux UserAccounts
==================
A brief description of the system accounts available in a |prod| system.
.. _overview-of-system-accounts-section-N1001F-N1001C-N10001:
**Sysadmin Local Linux Account**
This is a local, per-host, sudo-enabled account created automatically when
a new host is provisioned. It is used by the primary system administrator
for |prod|, as it has extended privileges.
------------------------
Types of System Accounts
------------------------
See :ref:`The sysadmin Account <the-sysadmin-account>` for more details.
- **sysadmin Local Linux Account**
This is a local, per-host, account created automatically when a new host
is provisioned. This account has extended privileges and is used by the
system administrator.
**Local Linux User Accounts**
Local Linux User Accounts should NOT be created since they are used for
internal system purposes.
- **Local Linux User Accounts**
These are local, regular Linux user accounts that are typically used for
internal system purposes and generally should not be created by an end
user.
**Local LDAP Linux User Accounts**
These are local LDAP accounts that are centrally managed across all hosts
in the cluster. These accounts are intended to provide additional admin
level user accounts \(in addition to sysadmin\) that can SSH to the nodes
of the |prod|.
If the administrator wants to provision additional access to the system,
it is better to configure local LDAP Linux accounts.
- **Local LDAP Linux User Accounts**
|prod| provides support for Local Ldap Linux User Accounts. Local LDAP
accounts are centrally managed; changes to local LDAP accounts made on
any host are propagated automatically to all hosts on the cluster.
|prod| includes a set of scripts for creating LDAP Linux accounts with
support for providing Keystone user account credentials. \(The scripts do
not create Keystone accounts for you. The scripts allow for sourcing or
accessing the Keystone user account credentials.\)
The intended use of these accounts is to provide additional admin level
user accounts \(in addition to sysadmin\) that can SSH to the nodes of
the |prod|.
See :ref:`Local LDAP Linux User Accounts <local-ldap-linux-user-accounts>`
for more details.
.. note::
For security reasons, it is recommended that ONLY admin level users
be allowed to SSH to the nodes of the |prod|. Non-admin level users
should strictly use remote CLIs or remote web GUIs..
These Local LDAP Linux user accounts can be associated with a Keystone
account. You can use the provided scripts to create these Local LDAP
Linux user accounts and synchronize them with the credentials of an
associated Keystone account, so that the Linux user can leverage
StarlingX CLI commands.
- **Kubernetes Service Accounts**
|prod| uses Kubernetes service accounts and |RBAC| policies for
authentication and authorization of users of the Kubernetes API, CLI, and
Dashboard.
- **Keystone Accounts**
|prod-long| uses Keystone for authentication and authorization of users
of the StarlingX REST APIs, the CLI, the Horizon Web interface and the
Local Docker Registry. |prod|'s Keystone uses the default local SQL
Backend.
- **Remote Windows Active Directory Accounts**
|prod| can optionally be configured to use remote Windows Active
Directory Accounts and native Kubernetes |RBAC| policies for
authentication and authorization of users of the Kubernetes API,
CLI, and Dashboard.
For security reasons, it is recommended that ONLY admin level users be
allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
strictly use remote |CLIs| or remote web GUIs.

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

@ -6,6 +6,10 @@
Password Recovery
=================
.. rubric:: |context|
This section describes how to change or reset a Keystone user password.
.. rubric:: |proc|
- Do one of the following to change a Keystone admin user password at any
@ -18,7 +22,7 @@ Password Recovery
.. code-block:: none
~(keystone_admin)$ openstack user password set
~(keystone_admin)]$ openstack user password set
.. warning::
Both controller nodes must be locked and unlocked after changing
@ -30,7 +34,7 @@ Password Recovery
.. code-block:: none
~(keystone_admin)$ openstack user set --password <temp_password> <user>
~(keystone_admin)]$ openstack user set --password <temp_password> <user>
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
================================
You can log in remotely as a Linux user using :command:`ssh`.
You can log in remotely as a Linux user\(either sysadmin or a local |LDAP|
user\) using :command:`ssh`.
.. note::
For security reasons, it is recommended that ONLY admin level users be
allowed to SSH to the nodes of the |prod|. Non-admin level users should
strictly use remote CLIs or remote web GUIs.
allowed to |SSH| to the nodes of the |prod|. Non-admin level users should
strictly use remote |CLIs| or remote web GUIs.
Specifying the OAM floating IP address as the target establishes a
connection to the currently active controller; however, if the OAM floating
Specifying the |OAM| floating IP address as the target establishes a
connection to the currently active controller; however, if the |OAM| floating
IP address moves from one controller node to another, the ssh session is
blocked. To ensure access to a particular controller regardless of its
current role, specify the controller physical address instead.

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

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:
- Obtain a Root |CA|-signed certificate and key from a trusted Root
|CA|. Refer to the documentation for the external Root |CA| that you
are using, on how to create public certificate and private key pairs,
signed by a Root |CA|, for HTTPS.
- Obtain an intermediate or Root |CA|-signed certificate and key from a
trusted intermediate or Root |CA|. Refer to the documentation for the
external intermediate or Root |CA| that you are using, on how to create
public certificate and private key pairs, signed by an intermediate or
Root-signed |CA|, for HTTPS.
.. xbooklink
For lab purposes, see :ref:`Locally Creating Certificates
<creating-certificates-locally-using-openssl>` for details on how to
create a test Root |CA| certificate and key, and use it to sign test
certificates.
<creating-certificates-locally-using-openssl>` for details on how to create
a test intermediate or Root |CA| certificate and key, and use it to sign
test certificates.
Put the |PEM| encoded versions of the certificate and key in a
single file, and copy the file to the controller host.
@ -88,8 +89,8 @@ re-installed, in order to update the new standby controller's |TPM| device.
**<pathTocertificateAndKey>**
is the path to the file containing both the Root |CA|-signed
certificate and private key to install.
is the path to the file containing both the intermediate or Root
|CA|-signed certificate and private key to install.
.. warning::
For security purposes, the utility deletes the provided SSL private
@ -159,7 +160,7 @@ scenario, you must reinstall the certificate:
.. code-block:: none
~(keystone_admin)$ system certificate-install -m tpm_mode
~(keystone_admin)]$ system certificate-install -m tpm_mode
<pathTocertificateAndKey>
To disable the use of |TPM| to store the private key of the StarlingX REST
@ -168,5 +169,5 @@ option:
.. code-block:: none
~(keystone_admin)$ system certificate-install <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
==================================================
The command line can be accessed from remote computers running Linux, OSX,
and Windows.
The |prod| command lines can be accessed from remote computers running Linux,
MacOS, and Windows.
.. rubric:: |context|
This functionality is made available using a docker image for connecting to
the |prod| remotely. This docker image is pulled as required by
configuration scripts.
This functionality is made available using a docker container with
pre-installed CLIs and clients. The container's image is pulled as required by
the remote CLI/client configuration scripts.
.. rubric:: |prereq|
@ -22,6 +22,21 @@ more information on installing Docker, see
`https://docs.docker.com/install/ <https://docs.docker.com/install/>`__.
For Windows remote clients, Docker is only supported on Windows 10.
.. note::
You must be able to run docker commands using one of the following options:
.. _security-configure-container-backed-remote-clis-and-clients-d70e42:
- Running the scripts using sudo
- Adding the Linux user to the docker group
For more information, see,
`https://docs.docker.com/engine/install/linux-postinstall/
<https://docs.docker.com/engine/install/linux-postinstall/>`__
For Windows remote clients, you must run the following commands from a
Cygwin terminal. See `https://www.cygwin.com/ <https://www.cygwin.com/>`__
for more information about the Cygwin project.
@ -33,23 +48,31 @@ Download the latest release tarball for Cygwin from
tarball, extract it to any location and change the Windows <PATH> variable
to include its bin folder from the extracted winpty folder.
The following procedure shows how to configure the Container-backed Remote
CLIs and Clients for an admin user with cluster-admin clusterrole. If using
a non-admin user such as one with role privileges only within a private
namespace, additional configuration is required in order to use
:command:`helm`.
The following procedure shows how to configure the Container-backed Remote CLIs
and Clients for an admin user with cluster-admin clusterrole. If using a
non-admin user such as one with privileges only within a private namespace,
additional configuration is required in order to use :command:`helm`.
.. rubric:: |proc|
.. _security-configure-container-backed-remote-clis-and-clients-d70e74:
.. _security-configure-container-backed-remote-clis-and-clients-d70e93:
#. On the Controller, configure a Kubernetes service account for user on the remote client.
You must configure a Kubernetes service account on the target system
and generate a configuration file based on that service account.
Run the following commands logged in as **root** on the local console of the controller.
Run the following commands logged in as **sysadmin** on the local console
of the controller.
#. Source the platform environment
.. code-block:: none
$ source /etc/platform/openrc
~(keystone_admin)]$
#. Set environment variables.
@ -60,14 +83,14 @@ namespace, additional configuration is required in order to use
.. code-block:: none
% USER="admin-user"
% OUTPUT_FILE="temp-kubeconfig"
~(keystone_admin)]$ USER="admin-user"
~(keystone_admin)]$ OUTPUT_FILE="temp-kubeconfig"
#. Create an account definition file.
.. code-block:: none
% cat <<EOF > admin-login.yaml
~(keystone_admin)]$ cat <<EOF > admin-login.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
@ -92,59 +115,54 @@ namespace, additional configuration is required in order to use
.. code-block:: none
% kubectl apply -f admin-login.yaml
~(keystone_admin)]$ kubectl apply -f admin-login.yaml
#. Store the token value.
.. code-block:: none
% TOKEN_DATA=$(kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep ${USER} | awk '{print $1}') | grep "token:" | awk '{print $2}')
~(keystone_admin)]$ TOKEN_DATA=$(kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep ${USER} | awk '{print $1}') | grep "token:" | awk '{print $2}')
#. Source the platform environment.
.. code-block:: none
% source /etc/platform/openrc
#. Store the OAM IP address.
#. Store the |OAM| IP address.
1. .. code-block:: none
#. .. code-block:: none
% OAM_IP=$(system oam-show |grep oam_floating_ip| awk '{print $4}')
~(keystone_admin)]$ OAM_IP=$(system oam-show |grep oam_floating_ip| awk '{print $4}')
2. AIO-SX uses <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
IP address.
.. code-block:: none
% if [ -z "$OAM_IP" ]; then
~(keystone_admin)]$ if [ -z "$OAM_IP" ]; then
OAM_IP=$(system oam-show |grep oam_ip| awk '{print $4}')
fi
3. IPv6 addresses must be enclosed in square brackets. The following shell code does this for you.
#. IPv6 addresses must be enclosed in square brackets. The following
shell code does this for you.
.. code-block:: none
% if [[ $OAM_IP =~ .*:.* ]]; then
~(keystone_admin)]$ if [[ $OAM_IP =~ .*:.* ]]; then
OAM_IP="[${OAM_IP}]"
fi
#. Generate the temp-kubeconfig file.
#. Generate the admin-kubeconfig file.
.. code-block:: none
% sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-cluster wrcp-cluster --server=https://${OAM_IP}:6443 --insecure-skip-tls-verify
% sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-credentials ${USER} --token=$TOKEN_DATA
% sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-context ${USER}@wrcp-cluster --cluster=wrcp-cluster --user ${USER} --namespace=default
% sudo kubectl config --kubeconfig ${OUTPUT_FILE} use-context ${USER}@wrcp-cluster
~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-cluster wrcp-cluster --server=https://${OAM_IP}:6443 --insecure-skip-tls-verify
~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-credentials ${USER} --token=$TOKEN_DATA
~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} set-context ${USER}@wrcp-cluster --cluster=wrcp-cluster --user ${USER} --namespace=default
~(keystone_admin)]$ sudo kubectl config --kubeconfig ${OUTPUT_FILE} use-context ${USER}@wrcp-cluster
#. On the remote client, install the remote client tarball file from the
StarlingX CENGEN build servers..
#. Copy the remote client tarball file from the |prod| build servers
to the remote workstation, and extract its content.
- The tarball is available from the |prod| area on the StarlingX CENGEN build servers.
@ -152,187 +170,162 @@ namespace, additional configuration is required in order to use
- You can extract the tarball's contents anywhere on your client system.
While it is not strictly required to extract the tarball before other
steps, subsequent steps in this example copy files to the extracted
directories as a convenience when running configuration scripts.
.. parsed-literal::
#. Download the openrc file from the Horizon Web interface to the remote client.
$ cd $HOME
$ tar xvf |prefix|-remote-clients-<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.
In this example, the 'admin' user in the 'admin' tenant.
#. Navigate to **Project** \> **API Access** \> **Download Openstack RC file**.
#. Select **Openstack RC file**.
The file admin-openrc.sh downloads.
#. Copy the temp-kubeconfig file to the remote workstation.
#. Copy the admin-kubeconfig file to the remote workstation.
You can copy the file to any location on the remote workstation. For
convenience, this example assumes that it is copied to the location of
the extracted tarball.
.. note::
Ensure the temp-kubeconfig file has 666 permissions after copying
Ensure that the admin-kubeconfig file has 666 permissions after copying
the file to the remote workstation, otherwise, use the following
command to change permissions, :command:`chmod 666 temp\_kubeconfig`.
#. On the remote client, configure the client access.
#. On the remote workstation, configure remote CLI/client access.
This step will also generate a remote CLI/client RC file.
#. Change to the location of the extracted tarball.
.. parsed-literal::
#. Run the :command:`configure\_client.sh` script to generate a client access file for the platform.
$ cd $HOME/|prefix|-remote-clients-<version>/
.. note::
For remote CLI commands that require local filesystem access,
you can specify a working directory when running
:command:`configure\_client.sh` using the -w option. If no
directory is specified, the location from which the
:command:`configure\_client.sh` was run is used for local file
access by remote cli commands. This working directory is
mounted at /wd in the docker container. If remote CLI commands
need access to local files, copy the files to your configured
work directory and then provide the command with the path to
the mounted folder inside the container.
#. Create a working directory that will be mounted by the container
implementing the remote |CLIs|.
See the description of the :command:`configure\_client.sh` -w option
:ref:`below
<security-configure-container-backed-remote-clis-and-clients>`
for more details.
.. code-block:: none
$ mkdir -p $HOME/remote_wd
$ ./configure_client.sh -t platform -r admin_openrc.sh -k temp-kubeconfig \
-w HOME/remote_wd
$ cd $HOME/remote_wd
$ mkdir -p $HOME/remote_cli_wd
By default, configure\_client.sh will use container images from
docker.io for both platform clients and openstack clients. You can
optionally use the -p and -a options to override the default docker
with one or two others from a custom registry. For example, to use
the container images from the WRS AWS ECR
#. Run the :command:`configure\_client.sh` script.
.. code-block:: none
$ ./configure_client.sh -t platform -r admin_openrc.sh -k
temp-kubeconfig -w HOME/remote_wd -p
625619392498.dkr.ecr.us-west-2.amazonaws.com/starlingx/stx-platfo
rmclients:stx.4.0-v1.3.0 -a
625619392498.dkr.ecr.us-west-2.amazonaws.com/starlingx/stx-openst
ackclients:master-centos-stable-latest
admin-kubeconfig -w HOME/remote_cli_wd -p
625619392498.dkr.ecr.us-west-2.amazonaws.com/docker.io/starlingx/stx-platfo
rmclients:stx.4.0-v1.3.0
If you are working with repositories that require authentication,
you must first perform a :command:`docker login` to that repository
before using remote clients.
If you specify repositories that require authentication, as shown
above, you must first remember to perform a :command:`docker login` to
that repository before using remote |CLIs| for the first time.
A remote\_client\_platform.sh file is generated for use accessing the platform CLI.
The options for configure\_client.sh are:
**-t**
The type of client configuration. The options are platform \(for
|prod-long| |CLI| and clients\) and openstack \(for |prod-os| application
|CLI| and clients\).
#. Test workstation access to the remote platform CLI.
The default value is platform.
Enter your platform password when prompted.
**-r**
The user/tenant RC file to use for :command:`openstack` CLI commands.
.. note::
The first usage of a command will be slow as it requires that the
docker image supporting the remote clients be pulled from the
remote registry.
The default value is admin-openrc.sh.
.. code-block:: none
**-k**
The kubernetes configuration file to use for :command:`kubectl` and :command:`helm` CLI commands.
root@myclient:/home/user/remote_wd# source remote_client_platform.sh
Please enter your OpenStack Password for project admin as user admin:
root@myclient:/home/user/remote_wd# system host-list
+----+--------------+-------------+----------------+-------------+--------------+
| id | hostname | personality | administrative | operational | availability |
+----+--------------+-------------+----------------+-------------+--------------+
| 1 | controller-0 | controller | unlocked | enabled | available |
| 2 | controller-1 | controller | unlocked | enabled | available |
| 3 | compute-0 | worker | unlocked | enabled | available |
| 4 | compute-1 | worker | unlocked | enabled | available |
+----+--------------+-------------+----------------+-------------+--------------+
root@myclient:/home/user/remote_wd# kubectl -n kube-system get pods
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-767467f9cf-wtvmr 1/1 Running 1 3d2h
calico-node-j544l 1/1 Running 1 3d
calico-node-ngmxt 1/1 Running 1 3d1h
calico-node-qtc99 1/1 Running 1 3d
calico-node-x7btl 1/1 Running 4 3d2h
ceph-pools-audit-1569848400-rrpjq 0/1 Completed 0 12m
ceph-pools-audit-1569848700-jhv5n 0/1 Completed 0 7m26s
ceph-pools-audit-1569849000-cb988 0/1 Completed 0 2m25s
coredns-7cf476b5c8-5x724 1/1 Running 1 3d2h
...
root@myclient:/home/user/remote_wd#
The default value is temp-kubeconfig.
.. note::
Some commands used by remote CLI are designed to leave you in a shell prompt, for example:
**-o**
The remote CLI/client RC file generated by this script.
This RC file needs to be sourced in the shell, to setup required
environment variables and aliases, before running any remote |CLI|
commands.
For the platform client setup, the default is
remote\_client\_platform.sh. For the openstack application client
setup, the default is remote\_client\_app.sh.
**-w**
The working directory that will be mounted by the container
implementing the remote |CLIs|. When using the remote |CLIs|, any files
passed as arguments to the remote |CLI| commands need to be in this
directory in order for the container to access the files. The default
value is the directory from which the :command:`configure\_client.sh`
command was run.
**-p**
Override the container image for the platform |CLI| and clients.
By default, the platform |CLIs| and clients container image is pulled
from docker.io/starlingx/stx-platformclients.
For example, to use the container images from the WRS AWS ECR:
.. code-block:: none
root@myclient:/home/user/remote_wd# openstack
$ ./configure_client.sh -t platform -r admin-openrc.sh -k
admin-kubeconfig -w $HOME/remote_cli_wd -p
625619392498.dkr.ecr.us-west-2.amazonaws.com/docker.io/starlingx/stx-platformclients:stx.4.0-v1.3.0-wrs.1
or
If you specify repositories that require authentication, you must first
perform a :command:`docker login` to that repository before using
remote |CLIs|.
.. code-block:: none
**-a**
Override the OpenStack application image.
root@myclient:/home/user/remote_wd# kubectl exec -ti <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
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.
The :command:`configure-client.sh` command will generate a remote\_client\_platform.sh RC file. This RC file needs to be sourced in the shell to set up required environment variables and aliases before any remote CLI commands can be run.
For example:
#. Copy the file remote\_client\_platform.sh to $HOME/remote\_cli\_wd
.. code-block:: none
.. rubric:: |postreq|
root@myclient:/home/user/remote_wd# FORCE_SHELL=true kubectl exec -ti <pod_name> -- /bin/bash
root@myclient:/home/user/remote_wd# FORCE_NO_SHELL=true kubectl exec <pod_name> -- ls
After configuring the platform's container-backed remote CLIs/clients, the
remote platform CLIs can be used in any shell after sourcing the generated
remote CLI/client RC file. This RC file sets up the required environment
variables and aliases for the remote |CLI| commands.
You cannot use both variables at the same time.
#. If you need to run a remote CLI command that references a local file,
then that file must be copied to or created in the working directory
specified on the ./config\_client.sh command and referenced as under /wd/
in the actual command.
For example:
.. code-block:: none
root@myclient:/home/user# cd $HOME/remote_wd
root@myclient:/home/user/remote_wd# kubectl -n kube-system create -f test/test.yml
pod/test-pod created
root@myclient:/home/user/remote_wd# kubectl -n kube-system delete -f test/test.yml
pod/test-pod deleted
#. Do the following to use helm.
.. note::
For non-admin users, additional configuration is required first as
discussed in *Configure Remote Helm Client for Non-Admin Users*.
.. note::
When using helm, any command that requires access to a helm
repository \(managed locally\) will require that you be in the
$HOME/remote\_wd directory and use the --home ./helm option.
#. Do the initial setup of the helm client.
.. code-block:: none
% helm init --client-only --home "./.helm"
#. Run a helm command.
.. code-block:: none
$ helm list
$ helm install --name wordpress stable/wordpress --home "./helm"
.. note::
Consider adding this command to your .login or shell rc file, such
that your shells will automatically be initialized with the environment
variables and aliases for the remote |CLI| commands.
See :ref:`Using Container-backed Remote CLIs and Clients <using-container-backed-remote-clis-and-clients>` for details.
**Related information**
.. 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
<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
~(keystone_admin)$ kubectl describe globalnetworkpolicy
~(keystone_admin)]$ kubectl describe globalnetworkpolicy
Name: controller-oam-if-gnp
Namespace:
Labels: <none>
@ -85,7 +85,7 @@ You can view the configured firewall rules with the following command:
Where:
.. _security-default-firewall-rules-d477e47:
.. _security-default-firewall-rules-d488e47:
.. table::

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

@ -6,25 +6,25 @@
Firewall Options
================
|prod| incorporates a default firewall for the OAM network. You can configure
|prod| incorporates a default firewall for the |OAM| network. You can configure
additional Kubernetes Network Policies in order to augment or override the
default rules.
The |prod| firewall uses the Kubernetes Network Policies \(using the Calico
CNI\) to implement a firewall on the OAM network.
|CNI|\) to implement a firewall on the |OAM| network.
A minimal set of rules is always applied before any custom rules, as follows:
.. _security-firewall-options-d628e35:
.. _security-firewall-options-ul-xw2-qkw-g3b:
- Non-OAM traffic is always accepted.
- Non-|OAM| traffic is always accepted.
- Egress traffic is always accepted.
- |SM| traffic is always accepted.
- SSH traffic is always accepted.
- |SSH| traffic is always accepted.
You can introduce custom rules by creating and installing custom Kubernetes

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:
- Non-OAM traffic is always accepted.
- Non-|OAM| traffic is always accepted.
- Egress traffic is always accepted.
- |SM| traffic is always accepted.
- SSH traffic is always accepted.
- |SSH| traffic is always accepted.
.. note::
It is recommended to disable port 80 when HTTPS is enabled for external
@ -35,7 +35,7 @@ Operational complexity:
.. _firewall-options-ul-hjq-k1g-mmb:
- |prod| provides OAM firewall rules through Kubernetes Network Policies.
- |prod| provides |OAM| firewall rules through Kubernetes Network Policies.
For more information, see :ref:`Firewall Options
<security-firewall-options>`.
@ -47,9 +47,9 @@ Operational complexity:
Default Firewall Rules
----------------------
|prod| applies these default firewall rules on the OAM network. The default
|prod| applies these default firewall rules on the |OAM| network. The default
rules are recommended for most applications.
For a complete listing, see :ref:`Default Firewall Rules
For a complete listings, see :ref:`Default Firewall Rules
<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
<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
<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|
By default a self-signed certificate is generated at installation time for
the registry API. For more secure access, a Root |CA|-signed certificate is
strongly recommended.
By default a self-signed certificate is generated at installation time for the
registry API. For more secure access, an intermediate or Root |CA|-signed
certificate is strongly recommended.
The Root |CA|-signed certificate for the registry must have at least the
following |SANs|: DNS:registry.local, DNS:registry.central, IP
Address:<oam-floating-ip-address>, IP Address:<mgmt-floating-ip-address>.
Use the :command:`system addrpool-list` command to get the |OAM| floating IP
The intermediate or Root |CA|-signed certificate for the registry must have at
least the following |SANs|: DNS:registry.local, DNS:registry.central, IP
Address:<oam-floating-ip-address>, IP Address:<mgmt-floating-ip-address>. Use
the :command:`system addrpool-list` command to get the |OAM| floating IP
Address and management floating IP Address for your system. You can add any
additional DNS entry\(s\) that you have set up for your |OAM| floating IP
Address.
Use the following procedure to install a Root |CA|-signed certificate to either
replace the default self-signed certificate or to replace an expired or soon
to expire certificate.
Use the following procedure to install an intermediate or Root |CA|-signed
certificate to either replace the default self-signed certificate or to replace
an expired or soon to expire certificate.
.. rubric:: |prereq|
Obtain a Root |CA|-signed certificate and key from a trusted Root |CA|. Refer
to the documentation for the external Root |CA| that you are using, on how to
create public certificate and private key pairs, signed by a Root |CA|, for
HTTPS.
Obtain an intermediate or Root |CA|-signed certificate and key from a trusted
intermediate or Root |CA|. Refer to the documentation for the external Root
|CA| that you are using, on how to create public certificate and private key
pairs, signed by an intermediate or Root |CA|, for HTTPS.
For lab purposes, see Appendix A for how to create a test Root |CA|
certificate and key, and use it to sign test certificates.
For lab purposes, see Appendix A for how to create a test intermediate or Root
|CA| certificate and key, and use it to sign test certificates.
Put the |PEM| encoded versions of the certificate and key in a single file,
and copy the file to the controller host.
Also, obtain the certificate of the Root |CA| that signed the above
certificate.
Also, obtain the certificate of the intermediate or Root |CA| that signed the
above certificate.
.. rubric:: |proc|
.. _security-install-update-the-docker-registry-certificate-d516e68:
.. _security-install-update-the-docker-registry-certificate-d527e71:
#. In order to enable internal use of the docker registry certificate,
update the trusted |CA| list for this system with the Root |CA| associated
@ -53,14 +53,15 @@ certificate.
.. code-block:: none
~(keystone_admin)$ system certificate-install --mode ssl_ca
~(keystone_admin)]$ system certificate-install --mode ssl_ca
<pathTocertificate>
where:
**<pathTocertificate>**
is the path to the Root |CA| certificate associated with the docker
registry Root |CA|-signed certificate.
is the path to the intermediate or Root |CA| certificate associated
with the docker registry's intermediate or Root |CA|-signed
certificate.
#. Update the docker registry certificate using the
:command:`certificate-install` command.
@ -69,13 +70,13 @@ certificate.
.. code-block:: none
~(keystone_admin)$ system certificate-install --mode docker_registry
~(keystone_admin)]$ system certificate-install --mode docker_registry
<pathTocertificateAndKey>
where:
**<pathTocertificateAndKey>**
is the path to the file containing both the docker registry
certificate and private key to install.
is the path to the file containing both the docker registry's
intermediate or Root CA-signed certificate and private key to install.

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
disabled; i.e. accessible via HTTP only.
For secure HTTPS access, an x509 certificate and key is required.
For secure HTTPS access, an x509 certificate and key is required. When HTTPS is
enabled for the first time on a |prod| system, a self-signed certificate and
key are automatically generated and installed for the StarlingX REST and Web
Server endpoints.
.. note::
The default HTTPS X.509 certificates that are used by |prod-long| for
authentication are not signed by a known authority. For increased
security, obtain, install, and use certificates that have been signed
by a Root certificate authority. Refer to the documentation for the
external Root |CA| that you are using, on how to create public
certificate and private key pairs, signed by a Root |CA|, for HTTPS.
Refer to the documentation for the external Intermediate or Root |CA| that
you are using, on how to create public certificate and private key pairs,
signed by an Intermediate or Root |CA|, for HTTPS.
By default a self-signed certificate and key is generated and installed by
|prod| for the StarlingX REST and Web Server endpoints for evaluation
purposes. This certificate and key is installed by default when HTTPS
access is first enabled for these services. In order to connect, remote
clients must be configured to accept the self-signed certificate without
verifying it \("insecure" mode\).
For secure remote access, a Root |CA|-signed certificate and key are
required. The use of a Root |CA|-signed certificate is strongly recommended.
For secure remote access, an intermediate or Root |CA|-signed certificate and
key are required. The use of a Root |CA|-signed certificate is strongly
recommended.
You can update the certificate used for HTTPS access at any time.

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\):
.. _starlingx-system-accounts-system-account-password-rules-ul-jwb-g15-zw:
.. _starlingx-system-accounts-system-account-password-rules-ul-evs-dsn-ynb:
- The password must be at least seven characters long.
@ -34,6 +34,8 @@ other Linux Accounts, and Keystone accounts\):
The following additional rules apply to Local Linux accounts only \(Local
LDAP, sysadmin, and other Linux accounts\):
.. _starlingx-system-accounts-system-account-password-rules-ul-rvj-jsn-ynb:
- Dictionary words or simple number sequences \(for example, 123 or 321\)
are not allowed

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
new host is provisioned.
This Linux user account is used by the system administrator as it has
This Linux user account is used by the primary system administrator as it has
extended privileges.
On controller nodes, this account is available even before :command:`ansible

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.
For more information, see :ref:`UEFI Secure Boot
For more information, see the section :ref:`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.
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>`.

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

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

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