2.2. 역할 기반 액세스 제어

Karaf의 역할 기반 액세스 제어는 다음과 같은 메커니즘을 기반으로 합니다.

역할 기반 액세스 제어의 Fuse 구현은 다음과 같은 유형의 보호 기능을 제공할 수 있습니다.

역할 기반 액세스 제어 시스템에서 사용자 인증 데이터에 역할을 추가하여 사용자에게 권한을 부여할 수 있습니다. 예를 들어 etc/users.properties 파일의 다음 항목은 admin 사용자를 정의하고 admin 역할을 부여합니다.

admin = secretpass,group,admin,manager,viewer,systembundles,ssh

또한 사용자 그룹을 정의한 다음 특정 사용자 그룹에 사용자를 할당할 수도 있습니다. 예를 들어 다음과 같이 admingroup 사용자 그룹을 정의하고 사용할 수 있습니다.

admin = secretpass, _g_:admingroup

_g_\:admingroup = group,admin,manager,viewer,systembundles,ssh

표 2.2. “액세스 제어를 위한 표준 역할” Cryostat ACL 및 명령 콘솔 ACL 전체에서 사용되는 표준 역할을 나열하고 설명합니다.

표준 ACL 파일 세트는 다음과 같이 Fuse 설치의 etc/auth/ 디렉터리에 있습니다.

전체 Cryostat ACL 파일 세트 및 명령 콘솔 ACL 파일은 기본적으로 제공됩니다. 시스템 요구 사항에 맞게 필요에 따라 이러한 ACL을 사용자 지정할 수 있습니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 다음 섹션에서 확인할 수 있습니다.

etc 디렉토리 아래의 system.properties 파일은 Karaf 명령 콘솔 및 Fuse 콘솔(Hawtio)을 통해 액세스를 제어하기 위해 다음과 같은 추가 속성을 제공합니다.

그림 2.1. “Access Control Mechanism for Cryostat” Karaf 컨테이너에 대한 Cryostat 연결에 대한 역할 기반 액세스 제어 메커니즘에 대한 개요를 보여줍니다.

그림 2.1. Access Control Mechanism for Cryostat

Cryostat 액세스 제어는 특수 javax.management.MBeanServer 오브젝트를 통해 Cryostat에 대한 원격 액세스를 제공하여 작동합니다. 이 오브젝트는 org.apache.karaf.management.KarafMBeanServerGuard 오브젝트를 호출하여 프록시 역할을 합니다. Cryostat 가드는 시작 파일에서 특별한 구성없이 사용할 수 있습니다.

Cryostat 액세스 제어는 다음과 같이 적용됩니다.

Cryostat ACL 파일은 InstallDir/etc/auth 디렉터리에 있습니다. 여기서 ACL 파일 이름은 다음 규칙을 따릅니다.

etc/auth/jmx.acl[.*].cfg

기술적으로 ACL은 패턴 jmx.acl[.*] 과 일치하는 OSGi 영구 ID(PID)에 매핑됩니다. 이는 Karaf 컨테이너가 기본적으로 etc/ 디렉터리 아래에 OSGi PID를 파일 PID.cfg 로 저장하는 것입니다.

Cryostat Guard는 Cryostat를 통해 액세스하는 모든 Cryostat 클래스에 액세스 제어를 적용합니다(사용자의 애플리케이션 코드에서 정의한 모든 Cryostat 포함). 특정 Cryostat 클래스의 ACL 파일은 jmx.acl 접두사를 추가하여 Cryostat의 오브젝트 이름에서 파생됩니다. 예를 들어 org.apache.camel:type=context 에서 Object Name이 지정하는 Cryostat가 있는 경우 해당 PID는 다음과 같습니다.

jmx.acl.org.apache.camel.context

OSGi Config Admin 서비스는 이 PID 데이터를 다음 파일에 저장합니다.

etc/auth/jmx.acl.org.apache.camel.context.cfg

Cryostat ACL 파일의 각 줄은 다음 형식의 항목입니다.

Pattern = Role1[,Role2][,Role3]...

여기서 Pattern 은 ScanSetting의 메서드 호출과 일치하는 패턴이며, 등호 오른쪽은 사용자에게 해당 호출을 수행할 수 있는 권한을 부여하는 쉼표로 구분된 역할 목록입니다. 가장 간단한 경우 Pattern 은 단순히 메서드 이름입니다. 예를 들어 jmx.acl.hawtio.OSGiTools Cryostat에 대한 다음 설정과 마찬가지로 ( jmx.acl.hawtio.OSGiTools.cfg 파일에서)

getResourceURL = admin, manager, viewer
getLoadClassOrigin = admin, manager, viewer

와일드카드 문자 * 를 사용하여 여러 메서드 이름과 일치시킬 수도 있습니다. 예를 들어 다음 항목은 set 로 시작하는 모든 메서드 이름을 호출할 수 있는 권한을 부여합니다.

set* = admin, manager, viewer

그러나 ACL 구문은 메서드 호출에 대한 훨씬 더 세분화된 제어를 정의할 수 있습니다. 특정 인수와 함께 호출된 메서드 또는 정규식과 일치하는 인수와 일치하도록 패턴을 정의할 수 있습니다. 예를 들어 org.apache.karaf.config 에 대한 ACL은 일반 사용자가 민감한 구성 설정을 수정하지 못하도록 이 기능을 악용합니다. 이 패키지의 create 방법은 다음과 같이 제한됩니다.

create(java.lang.String)[/jmx[.]acl.*/] = admin
create(java.lang.String)[/org[.]apache[.]karaf[.]command[.]acl.+/] = admin
create(java.lang.String)[/org[.]apache[.]karaf[.]service[.]acl.+/] = admin
create(java.lang.String) = admin, manager

이 경우 manager 역할에는 일반적으로 create 메서드를 호출할 수 있는 권한이 있지만 admin 역할만 jmx.acl.*, org.apache.karaf.command.acl.* 또는 org.apache.karaf.service.* 와 일치하는 PID 인수를 사용하여 create 를 호출할 수 있는 권한이 있습니다.

ACL 파일 형식에 대한 자세한 내용은 etc/auth/jmx.acl.cfg 파일의 주석을 참조하십시오.

모든 단일 Cryostat에 대해 ACL 파일을 제공하는 것이 비실용적인 경우가 많으므로 해당 패키지의 모든 Cryostat에 대한 기본 설정을 제공하는 Java 패키지 수준에서 ACL 파일을 지정하는 옵션이 있습니다. 예를 들어 org.apache.cxf.Bus Cryostat는 다음 PID 수준에서 ACL 설정의 영향을 받을 수 있습니다.

jmx.acl.org.apache.cxf.Bus
jmx.acl.org.apache.cxf
jmx.acl.org.apache
jmx.acl.org
jmx.acl

가장 구체적인 PID(list의 상단)가 최소 특정 PID(list의 봇)보다 우선합니다.

루트 ACL 파일인 jmx.acl.cfg 는 모든 Cryostat에 대한 기본 ACL 설정을 제공하므로 특별한 경우입니다. 루트 ACL에는 기본적으로 다음과 같은 설정이 있습니다.

list* = admin, manager, viewer
get* = admin, manager, viewer
is* = admin, manager, viewer
set* = admin
* = admin

이는 일반적인 읽기 방법 패턴(list*, get*, is*)은 모든 표준 역할에서 액세스할 수 있지만 일반적인 쓰기 방법 패턴 및 기타 메서드(설정* 및 \* )는 관리자 역할인 admin 에서만 액세스할 수 있습니다.

etc/auth/jmx.acl[.*].cfg 에 제공된 표준 Cryostat ACL 파일의 대부분은 Cryostat 패키지에 적용됩니다. 예를 들어 org.apache.camel.endpoints 에 대한 ACL은 다음 권한으로 정의됩니다.

is* = admin, manager, viewer
get* = admin, manager, viewer
set* = admin, manager

자체 애플리케이션에서 사용자 지정 Cryostat를 정의하는 경우 이러한 사용자 지정 Cryostat는 ACL 메커니즘과 자동으로 통합되고 Karaf 컨테이너에 배포할 때 Cryostat Guard에 의해 보호됩니다. 그러나 기본적으로 your Cryostat는 일반적으로 기본 루트 ACL 파일인 jmx.acl.cfg 에서만 보호됩니다. 보다 세분화된 ACL을 정의하려면 표준 Cryostat ACL 파일 이름 지정 규칙을 사용하여 etc/auth 아래에 새 ACL 파일을 만듭니다.

예를 들어 사용자 지정 Cryostat 클래스에 Cryostat 개체 이름, org.example:type=MyMBean 이 있는 경우 etc/auth 디렉터리에 새 ACL 파일을 생성합니다.

jmx.acl.org.example.MyMBean.cfg

OSGi Config Admin 서비스는 동적이므로 시스템이 실행되는 동안 ACL 설정을 변경할 수 있으며 특정 사용자가 로그인되는 경우에도 변경할 수 있습니다. 따라서 시스템이 실행되는 동안 보안 위반을 발견하면 Karaf 컨테이너를 다시 시작할 필요 없이 관련 ACL 파일을 편집하여 시스템의 특정 부분에 대한 액세스를 즉시 제한할 수 있습니다.

그림 2.2. “OSGi 서비스의 제어 메커니즘 액세스” Karaf 컨테이너의 OSGi 서비스에 대한 역할 기반 액세스 제어 메커니즘에 대한 개요를 보여줍니다.

그림 2.2. OSGi 서비스의 제어 메커니즘 액세스

실제로 명령 콘솔 액세스 제어 메커니즘은 OSGi 서비스의 일반 액세스 제어 메커니즘을 기반으로 합니다. 따라서 콘솔 명령이 구현되고 OSGi 서비스로 노출됩니다. Karaf 콘솔 자체는 OSGi 서비스 레지스트리를 통해 사용 가능한 명령을 검색하고 OSGi 서비스로 명령에 액세스합니다. 따라서 OSGi 서비스의 액세스 제어 메커니즘을 사용하여 콘솔 명령에 대한 액세스를 제어할 수 있습니다.

OSGi 서비스 보안을 위한 메커니즘은 OSGi 서비스 레지스트리 후크를 기반으로 합니다. 이는 특정 소비자의 OSGi 서비스를 숨기고 OSGi 서비스를 프록시 서비스로 교체할 수 있는 고급 OSGi 기능입니다.

서비스 가 특정 OSGi 서비스에 대해 배치되면 OSGi 서비스에서 클라이언트 호출이 다음과 같이 진행됩니다.

해당 ACL 파일이 없는 명령에 대해 etc/system.properties 파일에서 karaf.secured.command.compulsory.roles 속성을 설정하여 보안 역할의 기본 목록을 지정합니다(콤마로 구분된 역할 목록으로 지정됨).

명령 콘솔 ACL 파일은 InstallDir/etc/auth 디렉터리에 있으며 접두사 org.apache.karaf.command.acl.

명령 콘솔 ACL 파일 이름은 다음 규칙을 따릅니다.

etc/auth/org.apache.karaf.command.acl.CommandScope.cfg

여기서 CommandScope 는 특정 Karaf 콘솔 명령의 접두사에 해당합니다. 예를 들어 feature:install 및 features:uninstall 명령은 해당 ACL 파일 org.apache.karaf.command.acl.features.cfg 가 있는 feature 명령 범위에 속합니다.

명령 콘솔 ACL 파일의 각 줄은 다음 형식의 항목입니다.

Pattern = Role1[,Role2][,Role3]...

여기서 Pattern 은 현재 명령 범위의 Karaf console 명령과 일치하는 패턴이며 등호 오른쪽은 사용자가 해당 호출을 수행할 수 있는 권한을 부여하는 쉼표로 구분된 역할 목록입니다. 가장 간단한 경우 Pattern 은 단순히 범위가 지정되지 않은 명령 이름입니다. 예를 들어 org.apache.karaf.command.acl.feature.cfg ACL 파일에는 기능 명령에 대한 다음 규칙이 포함됩니다.

list = admin, manager, viewer
repo-list = admin, manager, viewer
info = admin, manager, viewer
version-list = admin, manager, viewer
repo-refresh = admin, manager
repo-add = admin, manager
repo-remove = admin, manager
install = admin
uninstall = admin

특정 인수와 함께 호출된 명령 또는 정규식과 일치하는 인수와 일치하도록 패턴을 정의할 수도 있습니다. 예를 들어 org.apache.karaf.command.acl.bundle.cfg ACL 파일은 일반 사용자가 -f (force) 플래그를 사용하여 bundle:start 및 bundle:stop 명령을 호출하지 못하도록 합니다(시스템 번들을 관리하도록 지정해야 함). 이 제한은 ACL 파일에서 다음과 같이 코딩됩니다.

start[/.*[-][f].*/] = admin
start = admin, manager
stop[/.*[-][f].*/] = admin
stop = admin, manager

이 경우 manager 역할에는 일반적으로 bundle:start 및 bundle:stop 명령을 호출할 수 있는 권한이 있지만 admin 역할만 force 옵션 -f 를 사용하여 이러한 명령을 호출할 수 있는 권한이 있습니다.

ACL 파일 형식에 대한 자세한 내용은 etc/auth/org.apache.karaf.command.acl.bundle.cfg 파일에서 주석을 참조하십시오.

명령 콘솔 ACL 설정은 완전히 동적이므로 시스템이 실행되는 동안 ACL 설정을 변경할 수 있으며 변경 사항은 이미 로그인한 사용자에게도 몇 초 내에 적용됩니다.

OSGi 서비스 ACL 파일에는 다음과 같이 이 ACL이 적용되는 OSGi 서비스를 식별하는 특수 항목이 한 개 있습니다.

service.guard = (objectClass=InterfaceName)

여기서 service.guard 는 일치하는 OSGi 서비스를 선택하기 위해 OSGi 서비스 속성의 레지스트리에 적용되는 LDAP 검색 필터입니다. 가장 간단한 유형의 필터 (objectClass=InterfaceName) 는 지정된 Java 인터페이스 이름 InterfaceName 을 사용하여 OSGi 서비스를 선택합니다.

ACL 파일의 나머지 항목은 다음과 같습니다.

Pattern = Role1[,Role2][,Role3]...

Pattern 은 서비스 방법과 일치하는 패턴이며 등호 오른쪽은 사용자에게 해당 호출을 수행할 수 있는 권한을 부여하는 쉼표로 구분된 역할 목록입니다. 이러한 항목의 구문은 기본적으로 Cryostat ACL 파일의 항목과 동일합니다. “ACL 파일 형식” 을 참조하십시오.

사용자 지정 OSGi 서비스에 대한 ACL을 정의하려면 다음 단계를 수행합니다.

사용자 지정 OSGi 서비스(즉, OSGi 서비스의 클라이언트 구현)에서 메서드를 호출하기 위해 Java 코드를 작성하는 경우 Java 보안 API를 사용하여 서비스를 호출하는 데 사용 중인 역할을 지정해야 합니다. 예를 들어 manager 역할을 사용하여 MyService OSGi 서비스를 호출하려면 다음과 같은 코드를 사용할 수 있습니다.

// Java
import javax.security.auth.Subject;
import org.apache.karaf.jaas.boot.principal.RolePrincipal;
// ...
Subject s = new Subject();
s.getPrincipals().add(new RolePrincipal("Deployer"));
Subject.doAs(s, new PrivilegedAction() {
  public Object run() {
    svc.doit("foo"); // invoke the service
  }
}

ACL로 보안된 OSGi 서비스에 대해 코드를 작성하는 경우 서비스를 호출할 수 있는 역할을 확인하는 것이 유용할 수 있습니다. 이를 위해 프록시 서비스는 추가 OSGi 속성 org.apache.karaf.service.guard.roles 를 내보냅니다. 이 속성의 값은 해당 서비스에서 메서드를 호출할 수 있는 모든 역할 목록을 포함하는 java.util.Collection 개체입니다.