Managing ACF: Difference between revisions

From Alpine Linux
(replace /etc/init.d with rc-service)
 
(One intermediate revision by one other user not shown)
Line 16: Line 16:
*Limit ACF access to specified IP or MAC addresses
*Limit ACF access to specified IP or MAC addresses


{{tip|By default, ACF use '''mini_httpd''' and use port '''443'''. If you would like to change this port you simply have to specify the port in '''/etc/mini_httpd/mini_httpd.conf''' and restart: '''/etc/init.d/mini_httpd restart'''}}
{{tip|By default, ACF use '''mini_httpd''' and use port '''443'''. If you would like to change this port you simply have to specify the port in '''/etc/mini_httpd/mini_httpd.conf''' and restart: '''rc-service mini_httpd restart'''}}


== User Management  ==
== User Management  ==
Line 24: Line 24:
In Alpine Linux 1.8, the system includes two default users: ''alpine'' and ''foo''. The default password for both users is ''test123''. '''Replace the default users as soon as possible.''' In Alpine Linux 1.9 and later, you will be prompted to create an initial user the first time you try to log in. If you install ACF using the '''setup-acf''' script, you will be prompted for a password, and a ''root'' user will be created.
In Alpine Linux 1.8, the system includes two default users: ''alpine'' and ''foo''. The default password for both users is ''test123''. '''Replace the default users as soon as possible.''' In Alpine Linux 1.9 and later, you will be prompted to create an initial user the first time you try to log in. If you install ACF using the '''setup-acf''' script, you will be prompted for a password, and a ''root'' user will be created.


{{Warning|If you did install ACF before define the root password, you must execute '''acfpasswd -s root'''}}
{{Warning|If you installed ACF before defining the root password, you must execute '''acfpasswd -s root'''}}


== Roles Management  ==
== Roles Management  ==

Latest revision as of 10:11, 17 November 2023

Managing Your ACF Installation

ACF is a powerful web application for configuring your Alpine Linux device. While all efforts are made to make ACF a secure application, it is, by its very nature, dangerous. The purpose of ACF is to give users the ability to administer the services running on the system. It is up to the system administrator to ensure that users do not receive more priviliges on ACF than they should have. Access control is provided by the following means:

  • System Configuration
  • User Management
  • Roles Management
  • Package-specific Management

System Configuration

System administrators can do much to limit inappropriate access to ACF by properly managing the firewall and http services on the Alpine Linux device. Lock down access to ACF as much as possible. The following steps are highly recommended:

  • Limit ACF to encrypted (HTTPS) access
  • Do not make ACF available on Internet connections (if possible)
  • Limit ACF access to specified IP or MAC addresses
Tip: By default, ACF use mini_httpd and use port 443. If you would like to change this port you simply have to specify the port in /etc/mini_httpd/mini_httpd.conf and restart: rc-service mini_httpd restart

User Management

ACF includes user management under the System | User Management menu. Select the New User button to create a new user. Separate user accounts should be created for each ACF user. Each user account may belong to any number of ACF roles.

In Alpine Linux 1.8, the system includes two default users: alpine and foo. The default password for both users is test123. Replace the default users as soon as possible. In Alpine Linux 1.9 and later, you will be prompted to create an initial user the first time you try to log in. If you install ACF using the setup-acf script, you will be prompted for a password, and a root user will be created.

Warning: If you installed ACF before defining the root password, you must execute acfpasswd -s root


Roles Management

ACF includes robust roles management under the System | Roles Management menu. Roles define the permissions that each user has in ACF. Specifically, they define which ACF actions a member of a role may invoke. The system provides built-in roles and the ability to create custom roles.

Built-in Roles

Each ACF package comes with built-in roles that define some typical usage scenarios. The five basic built-in roles are:

GUEST All users and guests (unauthenticated users) have access to basic status and login.
USER Typical end-users can view the status of services and restart them if necessary.
EDITOR Editors have the ability to change some settings using forms.
EXPERT Expert users can directly edit service configuration files.
ADMIN Administrators have access to all ACF actions.

These built-in roles can be selected on a controller-by-controller basis (ie. /alpine-baselayout/alpine-baselayout/ADMIN) or globally (ie. ADMIN). The global built-in roles consist of all of the permissions of all of the corresponding controller-by-controller roles (ie. ADMIN contains /x/y/ADMIN for every x and y installed).

ACF packages may also include built-in roles that define specific usage scenarios for that package. For instance, acf-openssl is a fully functional certificate authority that separates the roles of submitting and approving certificate requests:

CERT_REQUESTER Users may submit requests for certificates and download those certificates when approved.
CERT_APPROVER Users may approve certificate requests.

A system administrator may edit the built-in roles to add permissions, but may not delete the built-in roles or their default permissions. This feature may allow the system administrator to add some permission to one of the lower roles to meet his needs. This is the only way to modify the permissions of guests (unauthenticated users). More typically, a system administrator would assign each user to custom roles or to a combination of built-in and custom roles.

Custom Roles

Custom roles give the system administrator the ability to define roles that match the custom needs of his system. Custom roles may include as many or as few permissions as desired. So, a system administrator may fully define the permissions of each distinct user type in a separate role, or he may use combinations of more specific roles for each user.

Custom roles are created using the New Role button. The Create New Role and Edit Role forms list every ACF action currently installed on the system (depending on which ACF packages are installed). This list can be extensive if several ACF packages are installed. In general, each ACF package stands on its own, so permissions for one package do not depend on having permissions for any other packages. The built-in roles should be used as guides to show which permissions are typically grouped together.

Package-specific Management

ACF packages may include their own package-specific management.

acf-tinydns manages a tinydns DNS server and includes permissions management on a domain by domain basis. This is available under the Networking | DNS | Permissions tab. The tinydns ACF package is designed to keep configuration for each domain in a separate file (see the List Domains tab). Permissions can then be set as to which domains may be viewed / edited by a specific user or members of a particular role.

More Information

For more information, please see Alpine Configuration Framework Design.