分类 系统运维 下的文章

Linux Cockpit 是一个基于 Web 界面的应用,它提供了对系统的图形化管理。看下它能够控制哪些。

如果你还没有尝试过相对较新的 Linux Cockpit,你可能会对它所能做的一切感到惊讶。它是一个用户友好的基于 web 的控制台,提供了一些非常简单的方法来管理 Linux 系统 —— 通过 web。你可以通过一个非常简单的 web 来监控系统资源、添加或删除帐户、监控系统使用情况、关闭系统以及执行其他一些其他任务。它的设置和使用也非常简单。

虽然许多 Linux 系统管理员将大部分时间花在命令行上,但使用 PuTTY 等工具访问远程系统并不总能提供最有用的命令输出。Linux Cockpit 提供了图形和易于使用的表单,来查看性能情况并对系统进行更改。

Linux Cockpit 能让你查看系统性能的许多方面并进行配置更改,但任务列表可能取决于你使用的特定 Linux。任务分类包括以下内容:

  • 监控系统活动(CPU、内存、磁盘 IO 和网络流量) —— 系统
  • 查看系统日志条目 —— 日志
  • 查看磁盘分区的容量 —— 存储
  • 查看网络活动(发送和接收) —— 网络
  • 查看用户帐户 —— 帐户
  • 检查系统服务的状态 —— 服务
  • 提取已安装应用的信息 —— 应用
  • 查看和安装可用更新(如果以 root 身份登录)并在需要时重新启动系统 —— 软件更新
  • 打开并使用终端窗口 —— 终端

某些 Linux Cockpit 安装还允许你运行诊断报告、转储内核、检查 SELinux(安全)设置和列出订阅。

以下是 Linux Cockpit 显示的系统活动示例:

cockpit activity

Linux Cockpit 显示系统活动

如何设置 Linux Cockpit

在某些 Linux 发行版(例如,最新的 RHEL)中,Linux Cockpit 可能已经安装并可以使用。在其他情况下,你可能需要采取一些简单的步骤来安装它并使其可使用。

例如,在 Ubuntu 上,这些命令应该可用:

$ sudo apt-get install cockpit
$ man cockpit    <== just checking
$ sudo systemctl enable --now cockpit.socket
$ netstat -a | grep 9090
tcp6 0 0 [::]:9090 [::]:* LISTEN
$ sudo systemctl enable --now cockpit.socket
$ sudo ufw allow 9090

启用 Linux Cockpit 后,在浏览器中打开 https://<system-name-or-IP>:9090

可以在 Cockpit 项目 中找到可以使用 Cockpit 的发行版列表以及安装说明。

没有额外的配置,Linux Cockpit 将无法识别 sudo 权限。如果你被禁止使用 Cockpit 进行更改,你将会在你点击的按钮上看到一个红色的通用禁止标志。

要使 sudo 权限有效,你需要确保用户位于 /etc/group 文件中的 wheel(RHEL)或 adm (Debian)组中,即服务器当以 root 用户身份登录 Cockpit 并且用户在登录 Cockpit 时选择“重用我的密码”时,已勾选了 “Server Administrator”。

在你管理的系统位在千里之外或者没有控制台时,能使用图形界面控制也不错。虽然我喜欢在控制台上工作,但我偶然也乐于见到图形或者按钮。Linux Cockpit 为日常管理任务提供了非常有用的界面。


via: https://www.networkworld.com/article/3340038/linux/sitting-in-the-linux-cockpit.html

作者:Sandra Henry-Stocker 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

watchtopac 命令为我们监视 Linux 服务器上的活动提供了一些十分高效的途径。

为了在获取系统活动时更加轻松,Linux 系统提供了一系列相关的命令。在这篇文章中,我们就一起来看看这些对我们很有帮助的命令吧。

watch 命令

watch 是一个用来轻松地重复检测 Linux 系统中一系列数据命令,例如用户活动、正在运行进程、登录、内存使用等。这个命令实际上是重复地运行一个特定的命令,每次都会重写之前显示的输出,它提供了一个比较方便的方式用以监测在你的系统中发生的活动。

首先以一个基础且不是特别有用的命令开始,你可以运行 watch -n 5 date,然后你可以看到在终端中显示了当前的日期和时间,这些数据会每五秒更新一次。你可能已经猜到了,-n 5 选项指定了运行接下来一次命令需要等待的秒数。默认是 2 秒。这个命令将会一直运行并按照指定的时间更新显示,直到你使用 ^C 停下它。

Every 5.0s: date                             butterfly: Wed Jan 23 15:59:14 2019

Wed Jan 23 15:59:14 EST 2019

下面是一个更有趣的命令实例,你可以监控一个在服务器中登录用户的列表,该列表会按照指定的时间定时更新。就像下面写到的,这个命令会每 10 秒更新一次这个列表。登出的用户将会从当前显示的列表中消失,那些新登录的将会被添加到这个表格当中。如果没有用户再登录或者登出,这个表格跟之前显示的将不会有任何不同。

$ watch -n 10 who

Every 10.0s: who                             butterfly: Tue Jan 23 16:02:03 2019

shs      :0           2019-01-23 09:45 (:0)
dory     pts/0        2019-01-23 15:50 (192.168.0.5)
nemo     pts/1        2019-01-23 16:01 (192.168.0.15)
shark    pts/3        2019-01-23 11:11 (192.168.0.27)

如果你只是想看有多少用户登录进来,可以通过 watch 调用 uptime 命令获取用户数和负载的平均水平,以及系统的工作状况。

$ watch uptime

Every 2.0s: uptime                           butterfly: Tue Jan 23 16:25:48 2019

 16:25:48 up 22 days,  4:38,  3 users,  load average: 1.15, 0.89, 1.02

如果你想使用 watch 重复一个包含了管道的命令,就需要将该命令用引号括起来,就比如下面这个每五秒显示一次有多少进程正在运行的命令。

$ watch -n 5 'ps -ef | wc -l'

Every 5.0s: ps -ef | wc -l butterfly: Tue Jan 23 16:11:54 2019

245

要查看内存使用,你也许会想要试一下下面的这个命令组合:

$ watch -n 5 free -m

Every 5.0s: free -m butterfly: Tue Jan 23 16:34:09 2019

Every 5.0s: free -m                          butterfly: Tue Jan 23 16:34:09 2019

              total        used        free      shared  buff/cache   available
Mem:           5959         776        3276          12        1906        4878
Swap:          2047           0        2047

你可以在 watch 后添加一些选项查看某个特定用户下运行的进程,不过 top 为此提供了更好的选择。

top 命令

如果你想查看某个特定用户下的进程,top 命令的 -u 选项可以很轻松地帮你达到这个目的。

$ top -u nemo
top - 16:14:33 up 2 days,  4:27,  3 users,  load average: 0.00, 0.01, 0.02
Tasks: 199 total,   1 running, 198 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   5959.4 total,   3277.3 free,    776.4 used,   1905.8 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   4878.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
23026 nemo      20   0   46340   7820   6504 S   0.0   0.1   0:00.05 systemd
23033 nemo      20   0  149660   3140     72 S   0.0   0.1   0:00.00 (sd-pam)
23125 nemo      20   0   63396   5100   4092 S   0.0   0.1   0:00.00 sshd
23128 nemo      20   0   16836   5636   4284 S   0.0   0.1   0:00.03 zsh

你可能不仅可以看到某个用户下的进程,还可以查看每个进程所占用的资源,以及系统总的工作状况。

ac 命令

如果你想查看系统中每个用户登录的时长,可以使用 ac 命令。运行该命令之前首先需要安装 acct(Debian 等)或者 psacct(RHEL、Centos 等)包。

ac 命令有一系列的选项,该命令从 wtmp 文件中拉取数据。这个例子展示的是最近用户登录的总小时数。

$ ac
        total     1261.72

这个命令显示了用户登录的总的小时数:

$ ac -p
        shark                                5.24
        nemo                                 5.52
        shs                               1251.00
        total     1261.76

这个命令显示了每天登录的用户小时数:

$ ac -d | tail -10

Jan 11  total        0.05
Jan 12  total        1.36
Jan 13  total       16.39
Jan 15  total       55.33
Jan 16  total       38.02
Jan 17  total       28.51
Jan 19  total       48.66
Jan 20  total        1.37
Jan 22  total       23.48
Today   total        9.83

总结

Linux 系统上有很多命令可以用于检查系统活动。watch 命令允许你以重复的方式运行任何命令,并观察输出有何变化。top 命令是一个专注于用户进程的最佳选项,以及允许你以动态方式查看进程的变化,还可以使用 ac 命令检查用户连接到系统的时间。


via: https://www.networkworld.com/article/3335200/linux/how-to-monitor-activity-on-your-linux-server.html

作者:Sandra Henry-Stocker 选题:lujun9972 译者:dianbanjiu 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解一下配置管理工具,以找出哪个最适合你的 DevOps 组织。

DevOps 正因为有提高产品质量、缩短产品开发时间等优势,目前备受业界关注,同时也在长足发展当中。

DevOps 的核心价值观 团队文化 Culture 自动化 Automation 评估 Measurement 分享 Sharing (CAMS),同时,团队对 DevOps 的执行力也是 DevOps 能否成功的重要因素。

  • 团队文化让大家团结一致;
  • 自动化是 DevOps 的基础;
  • 评估保证了及时的改进;
  • 分享让 CAMS 成为一个完整的循环过程。

DevOps 的另一个思想是任何东西,包括服务器、数据库、网络、日志文件、应用配置、文档、自动化测试、部署流程等,都可以通过代码来管理。

在本文中,我主要介绍配置管理的自动化。配置管理工具作为 基础架构即代码 Infrastructure as Code (IaC)的一部分,支持使用经过测试和验证的软件开发实践,通过明文定义文件管理和配置数据中心。

DevOps 团队只需要通过操作简单的配置文件,就可以实现应用开发中包括版本控制、测试、小型部署、设计模式在内的这些最佳实践。总而言之,配置管理工具实现了通过编写代码来使基础架构的配置和管理变得自动化。

为什么要使用配置管理工具?

配置管理工具可以提高应用部署和变更的效率,还可以让这些流程变得可重用、可扩展、可预测,甚至让它们维持在期望的状态,从而让资产的可控性提高。

使用配置管理工具的优势还包括:

  • 让代码遵守编码规范,提高代码可读性;
  • 具有 幂等性 Idempotency ,也就是说,无论执行多少次重复的配置管理操作,得到的结果都是一致的;
  • 分布式的设计可以方便地管理大量的远程服务器。

配置管理工具主要分为 拉取 pull 模式和 推送 push 模式。拉取模式是指安装在各台服务器上的 代理 agent 定期从 中央存储库 central repository 拉取最新的配置并应用到对应的服务器上;而推送模式则由 中央服务器 central server 的中央服务器会触发其它受管服务器的更新。

五大最流行的配置管理工具

目前配置管理工具有很多,不同的配置管理工具都有自己最适合的使用场景。而对于下面五个我按照字母顺序列出的配置管理工具,都对 DevOps 有明显的帮助:全都具有开源许可证、使用外部配置文件、支持无人值守运行、可以通过脚本自定义运行。下面对它们的介绍都来源于它们的软件库和官网内容。

Ansible

“Ansible 是一个极其简洁的 IT 自动化平台,可以让你的应用和系统以更简单的方式部署。不需要安装任何代理,只需要使用 SSH 的方式和简单的语言,就可以免去脚本或代码部署应用的过程。”——GitHub Ansible 代码库

Ansible 是我最喜欢的工具之一,我在几年前就开始使用了。你可以使用 Ansible 在命令行中让多个服务器执行同一个命令,也可以使用 YAML 格式的 剧本 playbook 来让它自动执行特定的操作,这促进了技术团队和非技术团队之间的沟通。简洁、无代理、配置文件对非技术人员友好是它的几个主要优点。

由于 Ansible 不需要代理,因此对服务器的资源消耗会很少。Ansible 默认使用的推送模式需要借助 SSH 连接,但 Ansible 也支持拉取模式。剧本 可以使用最少的命令集编写,当然也可以扩展为更加精细的自动化任务,包括引入角色、变量和其它人写的模块。

你可以将 Ansible 和其它工具(包括 Ansible Works、Jenkins、RunDeck、ARA 等)结合起来使用,因为这些工具 提供了运行剧本时的可追溯性,这样就可以创建控制流程的中央控制台。

CFEngine

“CFEngine 3 是一个流行的开源配置管理系统,它主要用于为大规模的系统提供自动化配置和维护。”——GitHub CFEngine 代码库

CFEngine 最早在 1993 年由 Mark Burgess 作为自动配置管理的科学方法提出,目的是降低计算机系统配置中的熵,最终收敛到期望的配置状态,同时还阐述了幂等性是让系统达到期望状态的能力。Burgess 在 2004 年又提出了 承诺理论 Promise Theory ,这个理论描述了代理之间自发合作的模型。

CFEngine 的最新版本已经用到了承诺理论,在各个服务器上的代理程序会从中央存储库拉取配置。CFEngine 的配置对专业技能要求较高,因此它比较适合技术团队使用。

Chef

“为整个基础架构在配置管理上带来便利的一个系统集成框架。”——GitHub Chef 代码库

Chef 通过由 Ruby 编写的“ 菜谱 recipe ”来让你的基础架构保持在最新、最兼容的状态,这些“菜谱”描述了一系列应处于某种状态的资源。Chef 既可以通过客户端-服务端的模式运行,也可以在 chef-solo 这种独立配置的模式下运行。大部分云提供商都很好地集成了 Chef,因此可以使用它为新机器做自动配置。

Chef 有广泛的用户基础,同时也提供了完备的工具包,让不同技术背景的团队可以通过“菜谱”进行沟通。尽管如此,它仍然算是一个技术导向的工具。

Puppet

“Puppet 是一个可以在 Linux、Unix 和 Windows 系统上运行的自动化管理引擎,它可以根据集中的规范来执行诸如添加用户、安装软件包、更新服务器配置等等管理任务。”——GitHub Puppet 代码库

Puppet 作为一款面向运维工程师和系统管理员的工具,在更多情况下是作为配置管理工具来使用。它通过客户端-服务端的模式工作,使用代理从主服务器获取配置指令。

Puppet 使用 声明式语言 declarative language 或 Ruby 来描述系统配置。它包含了不同的模块,并使用 清单文件 manifest files 记录期望达到的目标状态。Puppet 默认使用推送模式,但也支持拉取模式。

Salt

“为大规模基础结构或应用程序实现自动化管理的软件。”——GitHub Salt 代码库

Salt 的专长就是快速收集数据,即使是上万台服务器也能够轻松完成任务。它使用 Python 模块来管理配置信息和执行特定的操作,这些模块可以让 Salt 实现所有远程操作和状态管理。但配置 Salt 模块对技术水平有一定的要求。

Salt 使用客户端-服务端的结构(Salt minions 是客户端,而 Salt master 是服务端),并以 Salt 状态文件记录需要达到的目标状态。

总结

DevOps 工具领域一直在发展,因此必须时刻关注其中的最新动态。希望这篇文章能够鼓励读者进一步探索相关的概念和工具。为此, 云原生计算基金会 Cloud Native Computing Foundation (CNCF)在 Cloud Native Landscape Project 中也提供了很好的参考案例。


via: https://opensource.com/article/18/12/configuration-management-tools

作者:Marco Bravo 选题:lujun9972 译者:HankChow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解自动化,使用 Git 存储库以及参数化 Jenkins 管道。

本文涵盖了三个关键主题:自动化 CI/CD 配置、使用 Git 存储库处理常见的 CI/CD 工件、参数化 Jenkins 管道。

术语

首先,我们定义一些术语。CI/CD 是允许团队快速自动化测试、打包、部署其应用程序的实践。它通常通过利用名为 Jenkins 的服务器来实现,该服务器充当 CI/CD 协调器。Jenkins 侦听特定输入(通常是代码签入后的 Git 挂钩),并在触发时启动一个管道。

管道 pipeline 由开发和/或运营团队编写的代码组成,这些代码指导 Jenkins 在 CI/CD 过程中采取哪些操作。这个流水线通常类似于“构建我的代码,然后测试我的代码,如果这些测试通过,则把我的应用程序部署到下一个最高环境(通常是开发、测试或生产环境)”。组织通常具有更复杂的管道,并入了诸如工件存储库和代码分析器之类的工具,这里提供了一个高级示例。

现在我们了解了关键术语,让我们深入研究一些最佳实践。

1、自动化是关键

要在 PaaS 上运行 CI/CD,需要在集群上配置适当的基础设施。在这个例子中,我将使用 OpenShift

“Hello, World” 的实现很容易实现。简单地运行 oc new-app jenkins-<persistent/ephemeral>,然后,你就有了一个已经就绪的运行中的 Jenkins 服务器了。然而,在企业中的使用要复杂得多。除了 Jenkins 服务器之外,管理员通常还需要部署代码分析工具(如 SonarQube)和工件库(如 Nexus)。然后,它们必须创建管道来执行 CI/CD 和 Jenkins 从服务器,以减少主服务器的负载。这些实体中的大多数都由 OpenShift 资源支持,需要创建这些资源来部署所需的 CI/CD 基础设施。

最后,部署 CI/CD 组件所需要的手动步骤可能是需要重复进行的,而且你可能不想成为执行那些重复步骤的人。为了确保结果能够像以前一样快速、无错误和准确地产生,应该在创建基础设施的方式中结合自动化方法。这可以是一个 Ansible 剧本、一个 Bash 脚本,或者任何您希望自动化 CI/CD 基础设施部署的其它方式。我已经使用 AnsibleOpenShift-Applier 角色来自动化我的实现。您可能会发现这些工具很有价值,或者您可能会发现其他一些对您和组织更有效的工具。无论哪种方式,您都将发现自动化显著地减少了重新创建 CI/CD 组件所需的工作量。

配置 Jenkins 主服务器

除了一般的“自动化”之外,我想单独介绍一下 Jenkins 主服务器,并讨论管理员如何利用 OpenShift 来自动化配置 Jenkins。来自 Red Hat Container Catalog 的 Jenkins 镜像已经安装了 OpenShift-Sync plugin。在 该视频 中,我们将讨论如何使用这个插件来创建 Jenkins 管道和从设备。

要创建 Jenkins 管道,请创建一个类似于下面的 OpenShift BuildConfig:

apiVersion: v1
kind: BuildConfig
...
spec:  
  source:      
    git:  
      ref: master      
      uri: <repository-uri>  
  ...  
  strategy:    
    jenkinsPipelineStrategy:    
      jenkinsfilePath: Jenkinsfile      
    type: JenkinsPipeline

OpenShift-Sync 插件将注意到已经创建了带有 jenkinsPipelineStrategy 策略的 BuildConfig,并将其转换为 Jenkins 管道,从 Git 源指定的 Jenkinsfile 中提取。也可以使用内联 Jenkinsfile,而不是从 Git 存储库中提取。有关更多信息,请参阅文档

要创建 Jenkins 从站,请创建一个 OpenShift ImageStream,它从以下定义开始:

apiVersion: v1
kind: ImageStream
metadata:
  annotations:
    slave-label: jenkins-slave
    labels:
      role: jenkins-slave
...

注意在这个 ImageStream 中定义的元数据。OpenShift-Sync 插件将把带有标签 role: jenkins-slave 的任何 ImageStream 转换为 Jenkins 从站。Jenkins 从站将以 slave-label 注释中的值命名。

ImageStreams 对于简单的 Jenkins 从属配置工作得很好,但是一些团队会发现有必要配置一些细节详情,比如资源限制、准备就绪和活动性探测,以及实例上限。这就是 ConfigMap 发挥作用的地方:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
  role: jenkins-slave
...
data:
  template1: |-
    <Kubernetes pod template>

注意,仍然需要角色:jenkins-slave 标签来将 ConfigMap 转换为 Jenkins 从站。Kubernetes pod 模板由一长段 XML 组成,它将根据组织的喜好配置每个细节。要查看此 XML,以及有关将 ImageStreams 和 ConfigMaps 转换为 Jenkins 从站的更多信息,请参阅文档

请注意上面所示的三个示例,其中没有一个操作需要管理员对 Jenkins 控制台进行手动更改。通过使用 OpenShift 资源,可以简单的自动化方式配置 Jenkins。

2、分享就是关爱

第二个最佳实践是维护一个公共 CI/CD 工件的 Git 存储库。主要思想是防止团队重新发明轮子。假设您的团队需要执行到 OpenShift 环境的蓝/绿部署,作为管道 CD 阶段的一部分。负责编写管道的团队成员可能不是 OpenShift 专家,也不可能具有从头开始编写此功能的能力。幸运的是,有人已经编写了一个将此功能合并到一个公共 CI/CD 存储库中的函数,因此您的团队可以使用该函数而不是花时间编写一个函数。

为了更进一步,您的组织可能决定维护整个管道。您可能会发现团队正在编写具有相似功能的管道。对于那些团队来说,使用来自公共存储库的参数化管道要比从头开始编写自己的管道更有效。

3、少即是多

正如我在前一节中提到的,第三个也是最后一个最佳实践是参数化您的 CI/CD 管道。参数化将防止过多的管道,使您的 CI/CD 系统更容易维护。假设我有多个区域可以部署应用程序。如果没有参数化,我需要为每个区域设置单独的管道。

要参数化一个作为 OpenShift 构建配置编写的管道,请将 env 节添加到配置:

...
spec:
  ...
  strategy:
    jenkinsPipelineStrategy:
      env:
      - name: REGION
        value: US-West          
      jenkinsfilePath: Jenkinsfile      
    type: JenkinsPipeline

使用此配置,我可以传递 REGION 参数给管道以将我的应用程序部署到指定区域。

这有一个视频提供了一个更实质性的情况,其中参数化是必须的。一些组织决定把他们的 CI/CD 管道分割成单独的 CI 和 CD 管道,通常是因为在部署之前有一些审批过程。假设我有四个镜像和三个不同的环境要部署。如果没有参数化,我需要 12 个 CD 管道来允许所有部署可能性。这会很快失去控制。为了使 CD 流水线的维护更容易,组织会发现将镜像和环境参数化以便允许一个流水线执行多个流水线的工作会更好。

总结

企业级的 CI/CD 往往比许多组织预期的更加复杂。幸运的是,对于 Jenkins,有很多方法可以无缝地提供设置的自动化。维护一个公共 CI/CD 工件的 Git 存储库也会减轻工作量,因为团队可以从维护的依赖项中提取而不是从头开始编写自己的依赖项。最后,CI/CD 管道的参数化将减少必须维护的管道的数量。

如果您找到了其他不可或缺的做法,请在评论中分享。


via: https://opensource.com/article/18/11/best-practices-cicd

作者:Austin Dewey 选题:lujun9972 译者:ChiZelin 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

不要只测试已有系统,强安全要求更积极主动的策略。

我们当中有多少人曾说出过下面这句话:“我希望这能起到作用!”?

毫无疑问,我们中的大多数人可能都不止一次地说过这句话。这句话不是用来激发信心的,相反它揭示了我们对自身能力和当前正在测试的功能的怀疑。不幸的是,这句话非常好地描述了我们传统的安全模型。我们的运营基于这样的假设,并希望我们实施的控制措施 —— 从 web 应用的漏扫到终端上的杀毒软件 —— 防止恶意的病毒和软件进入我们的系统,损坏或偷取我们的信息。

渗透测试通过积极地尝试侵入网络、向 web 应用注入恶意代码或者通过发送钓鱼邮件来传播病毒等等这些步骤来避免我们对假设的依赖。由于我们在不同的安全层面上来发现和渗透漏洞,手动测试无法解决漏洞被主动打开的情况。在安全实验中,我们故意在受控的情形下创造混乱,模拟事故的情形,来客观地检测我们检测、阻止这类问题的能力。

“安全实验为分布式系统的安全性实验提供了一种方法,以建立对抗恶意攻击的能力的信心。”

在分布式系统的安全性和复杂性方面,需要反复地重申混沌工程界的一句名言,“希望不是一种有效的策略”。我们多久会主动测试一次我们设计或构建的系统,来确定我们是否已失去对它的控制?大多数组织都不会发现他们的安全控制措施失效了,直到安全事件的发生。我们相信“安全事件不是侦察措施”,而且“希望不要出事也不是一个有效的策略”应该是 IT 专业人士执行有效安全实践的口号。

行业在传统上强调预防性的安全措施和纵深防御,但我们的任务是通过侦探实验来驱动对安全工具链的新知识和见解。因为过于专注于预防机制,我们很少尝试一次以上地或者年度性地手动测试要求的安全措施,来验证这些控件是否按设计的那样执行。

随着现代分布式系统中的无状态变量的不断改变,人们很难充分理解他们的系统的行为,因为会随时变化。解决这个问题的一种途径是通过强大的系统性的设备进行检测,对于安全性检测,你可以将这个问题分成两个主要方面:测试,和我们称之为实验的部分。测试是对我们已知部分的验证和评估,简单来说,就是我们在开始找之前,要先弄清楚我们在找什么。另一方面,实验是去寻找获得我们之前并不清楚的见解和知识。虽然测试对于一个成熟的安全团队来说是一项重要实践,但以下示例会有助于进一步地阐述两者之间的差异,并对实验的附加价值提供一个更为贴切的描述。

示例场景:精酿啤酒

思考一个用于接收精酿啤酒订单的 web 服务或者 web 应用。

这是这家精酿啤酒运输公司的一项重要服务,这些订单来自客户的移动设备、网页,和通过为这家公司精酿啤酒提供服务的餐厅的 API。这项重要服务运行在 AWS EC2 环境上,并且公司认为它是安全的。这家公司去年成功地通过了 PCI 规则,并且每年都会请第三方进行渗透测试,所以公司认为这个系统是安全的。

这家公司有时一天两次部署来进行 DevOps 和持续交付工作,公司为其感到自豪。

在了解了混沌工程和安全实验方面的东西后,该公司的开发团队希望能确定,在一个连续不断的基础上,他们的安全系统对真实世界事件的有效性和快速恢复性怎么样。与此同时,确保他们不会把安全控件不能检测到的新问题引入到系统中。

该团队希望能小规模地通过评估端口安全和防火墙设置来让他们能够检测、阻止和警告他们 EC2 安全组上端口设置的错误配置更改。

  • 该团队首先对他们正常状态下的假设进行总结。
  • 在 EC2 实例里为端口安全进行一个假设。
  • 为未认证的端口改变实验选择和配置 YAML 文件。
  • 该配置会从已选择的目标中随机指定对象,同时端口的范围和数量也会被改变。
  • 团队还会设置进行实验的时间并缩小爆破攻击的范围,来确保对业务的影响最小。
  • 对于第一次测试,团队选择在他们的测试环境中运行实验并运行一个单独的测试。
  • 在真实的 游戏日 Game Day 风格里,团队在预先计划好的两个小时的窗口期内,选择 灾难大师 Master of Disaster 来运行实验。在那段窗口期内,灾难大师会在 EC2 实例安全组中的一个实例上执行这次实验。
  • 一旦游戏日结束,团队就会开始进行一个彻底的、免于指责的事后练习。它的重点在于针对稳定状态和原始假设的实验结果。问题会类似于下面这些:

事后验证问题

  • 防火墙是否检测到未经授权的端口更改?
  • 如果更改被检测到,更改是否会被阻止?
  • 防火墙是否会将有用的日志信息记录到日志聚合工具中?
  • SIEM 是否会对未经授权的更改发出警告?
  • 如果防火墙没有检测到未经授权的更改,那么配置的管理工具是否发现了这次更改?
  • 配置管理工具是否向日志聚合工具报告了完善的信息?
  • SIEM 最后是否进行了关联报警?
  • 如果 SIEM 发出了警报,安全运营中心是否能收到这个警报?
  • 获得警报的 SOC 分析师是否能对警报采取措施,还是缺少必要的信息?
  • 如果 SOC 确定警报是真实的,那么安全事件响应是否能简单地从数据中进行分类活动?

我们系统中对失败的承认和预期已经开始揭示我们对系统工作的假设。我们的使命是利用我们所学到的,并更加广泛地应用它。以此来真正主动地解决安全问题,来超越当前传统主流的被动处理问题的安全模型。

随着我们继续在这个新领域内进行探索,我们一定会发布我们的研究成果。如果您有兴趣想了解更多有关研究的信息或是想参与进来,请随时联系 Aaron Rinehart 或者 Grayson Brewer。

特别感谢 Samuel Roden 对本文提供的见解和想法。


via: https://opensource.com/article/18/4/new-approach-security-instrumentation

作者:Aaron Rinehart 选题:lujun9972 译者:hopefully2333 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

现在,大多数公司都试图将它们的 IT 基础设施和电信设施迁移到私有云, 如 OpenStack。如果你打算面试 OpenStack 管理员这个岗位,那么下面列出的这些面试问题可能会帮助你通过面试。

Q:1 说一下 OpenStack 及其主要组件?

答: OpenStack 是一系列开源软件,这些软件组成了一个云供给软件,也就是 OpenStack,意即开源软件或项目栈。

下面是 OpenStack 的主要关键组件:

  • Nova – 用于在计算级别管理虚拟机,并在计算或管理程序级别执行其他计算任务。
  • Neutron – 为虚拟机、计算和控制节点提供网络功能。
  • Keystone – 为所有云用户和 OpenStack 云服务提供身份认证服务。换句话说,我们可以说 Keystone 是一个提供给云用户和云服务访问权限的方法。
  • Horizon – 用于提供图形用户界面。使用图形化管理界面可以很轻松地完成各种日常操作任务。
  • Cinder – 用于提供块存储功能。通常来说 OpenStack 的 Cinder 中集成了 Chef 和 ScaleIO 来共同为计算和控制节点提供块存储服务。
  • Swift – 用于提供对象存储功能。通常来说,Glance 管理的镜像是存储在对象存储空间的。像 ScaleIO 这样的外部存储也可以提供对象存储,可以很容易的集成 Glance 服务。
  • Glance – 用于提供镜像服务。使用 Glance 的管理平台来上传和下载云镜像。
  • Heat – 用于提供编排服务或功能。使用 Heat 管理平台可以轻松地将虚拟机作为堆栈,并且根据需要可以将虚拟机扩展或收缩。
  • Ceilometer – 用于提供计量与监控功能。

Q:2 什么服务通常在控制节点上运行?

答: 以下服务通常在控制节点上运行:

  • 认证服务(KeyStone)
  • 镜像服务(Glance)
  • Nova 服务比如 Nova API、Nova Scheduler 和 Nova DB
  • 块存储和对象存储服务
  • Ceilometer 服务
  • MariaDB / MySQL 和 RabbitMQ 服务
  • 网络(Neutron)和网络代理的管理服务
  • 编排服务(Heat)

Q:3 什么服务通常在计算节点上运行?

答: 以下服务通常在计算节点运行:

  • Nova 计算
  • 网络服务,比如 OVS

Q:4 计算节点上虚拟机的默认地址是什么?

答: 虚拟机存储在计算节点的 /var/lib/nova/instances

Q:5 Glance 镜像的默认地址是什么?

答: 因为 Glance 服务运行在控制节点上,所以 Glance 镜像都被存储在控制节点的 /var/lib/glance/images 文件夹下。

想了解更多请访问:在 OpenStack 中如何使用命令行创建和删除虚拟机

Q:6 说一下如何使用命令行启动一个虚拟机?

答: 我们可以使用如下 OpenStack 命令来启动一个新的虚拟机:

# openstack server create --flavor {flavor-name} --image {Image-Name-Or-Image-ID}  --nic net-id={Network-ID} --security-group {Security_Group_ID} –key-name {Keypair-Name} <VM_Name>

Q:7 如何在 OpenStack 中显示用户的网络命名空间列表?

答: 可以使用 ip net ns 命令来列出用户的网络命名空间。

~# ip netns list
qdhcp-a51635b1-d023-419a-93b5-39de47755d2d
haproxy
vrouter

Q:8 如何在 OpenStack 中执行网络命名空间内的命令?

答: 假设我们想在 qdhcp-a51635b1-d023-419a-93b5-39de47755d2d 网络命名空间中执行 ifconfig 命令,我们可以执行如下命令。

命令格式 : ip netns exec {network-space} <command>

~# ip netns exec qdhcp-a51635b1-d023-419a-93b5-39de47755d2d "ifconfig"

Q:9 在 Glance 服务中如何使用命令行上传和下载镜像?

答: Glance 服务中云镜像上传可以使用如下 OpenStack 命令:

~# openstack image create --disk-format qcow2 --container-format bare   --public --file {Name-Cloud-Image}.qcow2     <Cloud-Image-Name>

下载云镜像则使用如下命令:

~# glance image-download --file <Cloud-Image-Name> --progress  <Image-ID>

Q:10 OpenStack 如何将虚拟机从错误状态转换为活动状态?

答: 在某些情况下虚拟机可能会进入错误状态,可以使用如下命令将错误状态转换为活动状态:

~# nova reset-state --active {Instance_id}

Q:11 如何使用命令行来获取可使用的浮动 IP 列表?

答: 可使用如下命令来显示可用浮动 IP 列表:

~]# openstack ip floating list | grep None | head -10

Q:12 如何在特定可用区域中或在计算主机上配置虚拟机?

答: 假设我们想在 compute-02 中的可用区 NonProduction 上配置虚拟机,可以使用如下命令:

~]# openstack server create --flavor m1.tiny --image cirros --nic net-id=e0be93b8-728b-4d4d-a272-7d672b2560a6 --security-group NonProd_SG  --key-name linuxtec --availability-zone NonProduction:compute-02  nonprod_testvm

Q:13 如何在特定计算节点上获取配置的虚拟机列表?

答: 假设我们想要获取在 compute-0-19 中配置的虚拟机列表,可以使用如下命令:

命令格式: openstack server list –all-projects –long -c Name -c Host | grep -i {Compute-Node-Name}

~# openstack server list --all-projects --long -c Name -c Host | grep -i  compute-0-19

Q:14 如何使用命令行查看 OpenStack 实例的控制台日志?

答: 使用如下命令可查看实例的控制台日志。

首先获取实例的 ID,然后使用如下命令:

~# openstack console log show {Instance-id}

Q:15 如何获取 OpenStack 实例的控制台的 URL 地址?

答: 可以使用以下 OpenStack 命令从命令行检索实例的控制台 URL 地址:

~# openstack console url show {Instance-id}

Q:16 如何使用命令行创建可启动的 cinder / block 存储卷?

答: 假设创建一个 8GB 可启动存储卷,可参考如下步骤:

  • 使用如下命令获取镜像列表
~# openstack image list | grep -i cirros
| 89254d46-a54b-4bc8-8e4d-658287c7ee92 | cirros  | active |
  • 使用 cirros 镜像创建 8GB 的可启动存储卷
~# cinder create --image-id 89254d46-a54b-4bc8-8e4d-658287c7ee92 --display-name cirros-bootable-vol  8

Q:17 如何列出所有在你的 OpenStack 中创建的项目或用户?

答: 可以使用如下命令来检索所有项目和用户:

~# openstack project list --long

Q:18 如何显示 OpenStack 服务端点列表?

答: OpenStack 服务端点被分为 3 类:

  • 公共端点
  • 内部端点
  • 管理端点

使用如下 OpenStack 命令来查看各种 OpenStack 服务端点:

~# openstack catalog list

可通过以下命令来显示特定服务端点(比如说 keystone)列表:

~# openstack catalog show keystone

想了解更多请访问:OpenStack 中的实例创建流程

Q:19 在控制节点上你应该按照什么步骤来重启 nova 服务?

答: 应该按照如下步骤来重启 OpenStack 控制节点的 nova 服务:

  • service nova-api restart
  • service nova-cert restart
  • service nova-conductor restart
  • service nova-consoleauth restart
  • service nova-scheduler restart

Q:20 假如计算节点上为数据流量配置了一些 DPDK 端口,你如何检查 DPDK 端口的状态呢?

答: 因为我们使用 openvSwitch (OVS) 来配置 DPDK 端口,因此可以使用如下命令来检查端口的状态:

root@compute-0-15:~# ovs-appctl bond/show | grep dpdk
active slave mac: 90:38:09:ac:7a:99(dpdk0)
slave dpdk0: enabled
slave dpdk1: enabled
root@compute-0-15:~#
root@compute-0-15:~# dpdk-devbind.py --status

Q:21 如何使用命令行在 OpenStack 中向存在的安全组 SG(安全组)中添加新规则?

答: 可以使用 neutron 命令向 OpenStack 已存在的安全组中添加新规则:

~# neutron security-group-rule-create --protocol <tcp or udp>  --port-range-min <port-number> --port-range-max <port-number> --direction <ingress or egress>  --remote-ip-prefix <IP-address-or-range> Security-Group-Name

Q:22 如何查看控制节点和计算节点的 OVS 桥配置?

答: 控制节点和计算节点的 OVS 桥配置可使用以下命令来查看:

~]# ovs-vsctl show

Q:23 计算节点上的集成桥(br-int)的作用是什么?

答: 集成桥(br-int)对来自和运行在计算节点上的实例的流量执行 VLAN 标记和取消标记。

数据包从实例的 n/w 接口发出使用虚拟接口 qvo 通过 Linux 桥(qbr)。qvb 接口是用来连接 Linux 桥的,qvo 接口是用来连接集成桥的。集成桥上的 qvo 端口有一个内部 VLAN 标签,这个标签是用于当数据包到达集成桥的时候贴到数据包头部的。

Q:24 隧道桥(br-tun)在计算节点上的作用是什么?

答: 隧道桥(br-tun)根据 OpenFlow 规则将 VLAN 标记的流量从集成网桥转换为隧道 ID。

隧道桥允许不同网络的实例彼此进行通信。隧道有利于封装在非安全网络上传输的流量,它支持两层网络,即 GRE 和 VXLAN。

Q:25 外部 OVS 桥(br-ex)的作用是什么?

答: 顾名思义,此网桥转发来往网络的流量,以允许外部访问实例。br-ex 连接物理接口比如 eth2,这样用户网络的浮动 IP 数据从物理网络接收并路由到用户网络端口。

Q:26 OpenStack 网络中 OpenFlow 规则的作用是什么?

答: OpenFlow 规则是一种机制,这种机制定义了一个数据包如何从源到达目的地。OpenFlow 规则存储在 flow 表中。flow 表是 OpenFlow 交换机的一部分。

当一个数据包到达交换机就会被第一个 flow 表检查,如果不匹配 flow 表中的任何入口,那这个数据包就会被丢弃或者转发到其他 flow 表中。

Q:27 怎样查看 OpenFlow 交换机的信息(比如端口、表编号、缓存编号等)?

答: 假如我们要显示 OpenFlow 交换机的信息(br-int),需要执行如下命令:

root@compute-0-15# ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000fe981785c443
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(patch-tun): addr:3a:c6:4f:bd:3e:3b
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 2(qvob35d2d65-f3): addr:b2:83:c4:0b:42:3a
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 ………………………………………

Q:28 如何显示交换机中的所有 flow 的入口?

答: 可以使用命令 ovs-ofctl dump-flows 来查看交换机的 flow 入口。

假设我们想显示 OVS 集成桥(br-int)的所有 flow 入口,可以使用如下命令:

[root@compute01 ~]# ovs-ofctl dump-flows br-int

Q:29 什么是 Neutron 代理?如何显示所有 Neutron 代理?

答: OpenStack Neutron 服务器充当中心控制器,实际网络配置是在计算节点或者网络节点上执行的。Neutron 代理是计算节点或者网络节点上进行配置更新的软件实体。Neutron 代理通过 Neuron 服务和消息队列来和中心 Neutron 服务通信。

可通过如下命令查看 Neutron 代理列表:

~# openstack network agent list -c ‘Agent type’ -c Host -c Alive -c State

Q:30 CPU Pinning 是什么?

答: CPU Pinning 是指为某个虚拟机保留物理核心。它也称为 CPU 隔离或处理器关联。有两个目的:

  • 它确保虚拟机只能在专用核心上运行
  • 它还确保公共主机进程不在这些核心上运行

我们也可以认为 Pinning 是物理核心到一个用户虚拟 CPU(vCPU)的一对一映射。


via: https://www.linuxtechi.com/openstack-interview-questions-answers/

作者:Pradeep Kumar 选题:lujun9972 译者:ScarboroughCoral 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出