앞에 문서( https://cyuu.tistory.com/177 )에서 Ceph과 Openstack을 Podman 기반으로 배포하였다. 이제, KeyCloak을 배포하고 KeyStone 연동을 통하여 SSO 구성을 한다. 이전 배포 구성 환경에 대한 부분은 앞의 문서를 참고한다.
일반적으로 Openstack에서는 Keystone이라는 단독 인증 서비스를 통해서 User/Project 등 의 관리가 진행된다. 이러한 정보는 구축된 RDBMS에 저장된다 이러한 구성에서 다른 App 들처럼 Saml 등 다양한 연동을 구성하여 SingleSingOn을 구성할 수 있다.
이러한 연합의 메커니즘을 제공하는 것이 Keystone Federation이다. 우선. Keycloak에 OpenID Connect를 통한 구성 연동을 하기 전에 Keystone Federation에 대하여 확인한다.
Federation Keystone
Keystone Federation 은 말 그대로 연합의 Keysontone 구성하는 방식으로, 크게 두 가지 방식으로 나눠진다. SP(Service Provider) 역할로 서 외부의 Keycloak이나 Goolge 혹은 Facebook 등의 Idp를 이용하는 방법 혹은 Keystone에서 Keystone으로 연합하는 방법이 있다.
여기서 IdP 나 SP 용어가 나오는데 간단하게 아래와 같이 정의할 수 있다.
- Identity Provider (IdP): 사용자의 신원 정보를 관리하고 인증하는 서비스. 사용자는 IdP에 로그인하여 인증 (ex: Keycloak, Facebook, Github...)
- Service Provider (SP): IdP로부터 인증된 사용자가 접근하려는 서비스 또는 리소스를 제공자로 예를 들어, OpenStack 클라우드 환경이 SP 역할을 할 수 있다.
이러한 Federation 구성을 통하여 SSO이라는 큰 이점과 함께 별도의 IdP를 통하여 유연성과 확장성을 제공하여 Openstack의 기능을 확장해서 다양한 환경에 비즈니스에 적용할 수 있을 것이다.
Openid Connect
Federate Keystone (SP)를 외부의 IdP KeyCloack과 연동할 경우 사용되는 다양한 인증 프로토콜이 있는데 그중 Saml 기반의 방식에서 최근 몇 년 사이 OAuth2인가 기반 위에서 작동하는 Openid Connect(OIDC)가 많이 사용되고 있으며, Openstack에서도 Federate Keyctone 구성을 제공하고 있다.
더 정확하게는 OAuth2는 Authorization 표준이고 , 그위에서 OpenID Connect는 Authentication 표준을 기반으로 정의되었고, 지금지금 진행하려는 구성에서는 Keystone 단독 처리 하던 인가 인증을 에서 OAuth2 기반의 인가에서 OpenID Connect 인증을 KeyCloak 이 외부에서 대한 해준다 생각하면 된다,
다만 , 설정이 다소 복잡하고 트러블 슈팅 하기 힘든 이슈가 많았는데 최근 Kolla-ansible에서 OIDC 연동에 대한 자동화 부분이 추가되어 손쉽게 구성이 가능해졌다.
그래도 Oauth2와 OIDC에 대한 이해가 필수 적이다.
OIDC에 대한 자세한 부분은 외부 잘 작성된 글들이 많기 때문에 외부 문서를 참고한다.
https://www.samsungsds.com/kr/insights/oidc.html
https://devocean.sk.com/blog/techBoardDetail.do?ID=165453&boardType=techBlog
KeyCloak 구성
Keycloak(https://www.keycloak.org) 은 Single Sign-On (SSO)을 위하여 사용되는 대표적인 오픈소스로 , OpenID Connect (OIDC) 및 SAML 2.0 지원이 됨에 따라 다양한 Client와 통합에 용이하게 사용된다.
단순 인증/인가뿐만 아니라 Identity Brokering 역할로 외부의 Okta 나 Facebook, Google 등의 연동이 가능하다.
Keycloak를 통 구성된 deploy 서버에 podman을 이용하여 배포한다.
해당 구성에서는 배포할 Openstack에서 Keystone 인증에서 OIDC 연동을 하기 위하여 사용한다. 결국 Keystone Local DB에 접근하여 인증/인가하는 것이 아닌 Keycloak에서 진행을 하게 된다.
아래의 구성은 간단하게 테스트/개발을 위해서 올린 것으로 Container 실행 명령 자체도 start-dev으로 실 환경 적용을 위해서는 아래와 같은 방법이 아닌 별도의 외부 DB 등 Prod mode구동을 위한 조건으로 실행해야 한다.
KeyCloak 이 동작하는 호스트는 deploy 노드로, 해당 노드에 앞서 Registry를 생성하기 위해 설치했던 Podman을 활용하여 배포한다.
배포 시 인증서를 사용하는데 "/root/ssl/dev24 deploy.cyuucloud.xyz/" 디렉토리에 " dev24deploy.cyuucloud.xyz " 도메인에 대한 인증서를 미리 복사 했으며, 해당 인증서는 별도로 zero ssl 로 생성한 테스트용도 인증서 이다.
dev24deploy.cyuucloud.xyz 도메인은 deploy 노드의 공인 아이피로 레코드가 추가돼있으며, 결론적으로 KeyCloak을 외부에 접근 시 TLS 통신하기 위해서 구성되었다. (
참고 페이지 : https://www.keycloak.org/getting-started/getting-started-docker)
root@cyyoon-c1-deploy-010:~# podman run -id -d \
--network host \
--name cyyoon-keyloack \
-e KEYCLOAK_ADMIN=admin \
-e KEYCLOAK_ADMIN_PASSWORD=cyyoon_password \
-v /root/ssl/dev24deploy.cyuucloud.xyz/certificate.crt:/etc/ x509/https/tls.crt \
-v /root/ssl/dev24deploy.cyuucloud.xyz/private.key:/etc/x509/https/tls.key \
-v /root/ssl/dev24deploy.cyuucloud.xyz/ca_bundle.crt:/etc/x509/https/ca.crt \
quay.io/keycloak/keycloak:23.0.6 start-dev \
--https-certificate-file=/etc/x509/https/tls.crt \
--https-certificate-key-file=/etc/x509/https/tls.key
root@cyyoon-c1-deploy-010:~# podman ps |grep keycloak
a51686f729a5 quay.io/keycloak/keycloak:23.0.6 start-dev 10 seconds ago Up 10 seconds cyyoon-keyloack
웹 브라우저 상에서 Keycloak 웹 UI 접근을 위하여 "https://dev24 deploy.cyuucloud.xyz"로 접근하고 "Administration Console " 메뉴에 진입한다.
dev24 deploy.cyuucloud.xyz 는 이미 앞서 인증서 구성 과정에서 Deploy(cyyoon-c1-deploy-010) 서버에 설정된 공인 아이피로 A레코드가 등록된 상태로 접근 할 수 있다.
그 뒤 Podman으로 실행 시 설정한 admin 계정과 admin 계정의 비밀번호로 로그인을 한다.
이제 기본 설정 된 Keycloak의 Master Realm을 확인할 수 있다.
KeyCloak Client 구성
앞서 KeyCloak에 대한 기본 설치 후 Master Realm으로 해서 구축은 되었지만 Clinet 구성 및 접근할 UIser생성이 필요하다. 먼저 admin 외 일반 사용자 계정으로 아래와 같이 User 탭에서 계정을 생성해준다. 현 테스트에서는 cyyoon-test-001 이란 이름으로 생성했다.
생성된 계정에서 Credential 메뉴에 들어가면 비밀번호 설정이 가능하다. 접근할 비밀 번호를 설정한다.
Client 구성을 위하여 Client 탭에서 Create client 버튼을 클릭한다.
Client type 은 OpenID Connect로 하며, Client ID는 dev24 odic로 한다.
Authentication flow는 Standard flow와 Direct access grants로 성정 한다.
만약 Keystone에서 OIDC설정 중 Response Type을 ID token을 할 경우 Implicit flow으로 진행해야 하나 현 구성에서는 Response Type를 Code로 하기 때문에 해제하여 진행한다.
Valid redirect URIs에 Openstack Keystone의 VIP 정보로 추가해준다.
이제 Client 구성이 완료되어 정보를 확인할 수 있다. 추가적으로 해당 완료된 Client 설정에서 Credentials 설정에 들어가서 이후 Keystone에서 해당 IdP로 접근하여 Client 인증에 필요 한 Secret을 확인해둔다.
그리고 Realm Setting에서 기본 생성된 Master Realm의 Meatadata 인 Well-known를 다운로드하거나 외부에서 다운로드 가능하게 주소를 확인한다.
최종적으로 위 구성으로 통하여 Openstack에서 연동 시 필요 한 Keycloak(IdP)의 정보를 정리한다.
- Well-known 주소 : https://dev24 deploy.cyuucloud.xyz:8443/realms/master/. well-known/openid-configuration
- Client ID: dev24 oidc
- Client Secret: OQVmw1 JLEDJd44 P6 dkoupZPb3 qdECAAE
- Keycloak 주소 : https://dev24 deploy.cyuucloud.xyz:8443/
- 접근 User ID: cyyoon-test-001
Openstack(Kolla-ansible) 설정
Kolla-ansible에 설정을 추가하기 위하여 OIDC 디렉터리를 별도로 생성 Attribute Mapping과 Metadata 디렉토리를 생성해준다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# mkdir -p /home/kolla/sso/odic/attribute_mapping
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# mkdir -p /home/kolla/sso/odic/metadata
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# mkdir -p /home/kolla/sso/odic/metadata/dev24deploy.cyuucloud.xyz/
Metadata 에는 앞서 Client 설정 한 KeyCloak에 대한 Metadata와 Credential 정보를 보관된다. 여기서 파일 파일 이름은 반드시 해당 Provider 즉 IdP의 주소/경로 로 해야 하며, 해당 주소/경로를 그대로 사용하는데 경로에 들어가는 특수 문자는 URL-encoded처리해야 한다.
KeyCloak 기준을 Issuer를 well-known를 통하여 확인하고 프로토콜을 제외한 "dev24 deploy.cyuucloud.xyz:8443/realms/master" 이라는 주소를 넣어야 한다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# curl https://dev24deploy.cyuucloud.xyz:8443/realms/master/.well-known/openid-configuration -s | jq .issuer
"https://dev24deploy.cyuucloud.xyz:8443/realms/master"URL-encoded를 통하여 "dev24deploy.cyuucloud.xyz:8443/realms/master" 주소가 "dev24 deploy.cyuucloud.xyz%3A8443%2 Frealms%2 Fmaster"으로 변경된 것을 확인한다.
외부에 다양한 URL-encoded 툴 이 많으니 사용해서 처리하면 된다. 여기서 ":"는 %3A로 처리되며 "/"는 % 2A로 변환된다.
변환된 이름 기준으로 dev24 deploy.cyuucloud.xyz%3A8443%2 Frealms%2 Fmaster.client 파일에는 앞서 KeyCloak에서 설정한 Client ID와 Secret 정보를 Json 형태로 생성해준다.
dev24 deploy.cyuucloud.xyz%3A8443%2 Frealms%2 Fmaster.provider 는 Well-known 파일을 다운로드하여서 저장해준다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# cat /home/kolla/sso/odic/metadata/dev24deploy.cyuucloud.xyz/dev24deploy.cyuucloud.xyz%3A8443%2Frealms%2Fmaster.client
{
"client_id":"dev24oidc",
"client_secret":"OQVmw1JLEDJd44P6dkoupZPb3qdECAAE"
}
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# curl https://dev24deploy.cyuucloud.xyz:8443/realms/master/.well-known/openid-configuration > /home/kolla/sso/odic/metadata/dev24deploy.cyuucloud.xyz/dev24deploy.cyuucloud.xyz%3A8443%2Frealms%2Fmaster.provider
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6234 100 6234 0 0 54295 0 --:--:-- --:--:-- --:--:-- 54684
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# cat /home/kolla/sso/odic/metadata/dev24deploy.cyuucloud.xyz/dev24deploy.cyuucloud.xyz%3A8443%2Frealms%2Fmaster.provider
{"issuer":"https://dev24deploy.cyuucloud.xyz:8443/realms/master","authorization_endpoint":"https://dev24deploy.cyuucloud.xyz:844... 생략
이제 Attribute Mapping 설정을 한다. Mapping을 하는 것은 외부의 IdP의 계정/그룹 등의 정보와 Local에 있는 Keystone 이 각 속성이 다르기 때문에 맞춰주는 역할을 한다.
이러한 Mapping을 통하여 다양한 IdP와 프로토콜 간의 조합이 가능 해진다. 아래의 설정은 크게 local과 remote로 나눠지는데 local 에는 keystone 이 들어간 속성이 remote에는 keystone 이 들어가는 설정으로 KeyClaok에서 설정한 Tyep에 맞춰서 다양한 Remote 타입을 지정할 수 있다.
아래 구성에는 1개의 Type으로 OIDC-preferred_username 가 들어가는데, 이 Type의 Value 인 유저 ID 가 Local에서 "{0}"으로 들어가서 Keystone에서는 처음 로그인을 하게 되면 User Name과 Project를 "{0}" 변수에 맞게 들어가게 된다.
구성은 empty, any_one_of 조건 조합이나, regex와 같이 어떠한 Remote의 Type에 따라서 다양하게 처리 가능하다. 예를 들어 특정 유저만 특정 그룹으로 포함시키거나, 별도의 속성을 넣는 방법 등 다양하게 활용할 수 있다.
(공식 문서 설명 : https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html)
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# cat /home/kolla/sso/odic/attribute_mapping/dev24deploy.cyuucloud.xyz.keystone_identity_mapping.json
[
{
"local": [
{
"user": {
"name": "{0}"
}
},
{
"projects": [
{
"name": "project-{0}",
"roles": [
{
"name": "member"
}
]
}
]
}
],
"remote": [
{
"type": "OIDC-preferred_username"
}
]
}
]
globals.yml 에 위에서 진행 한 설정을 추가해주고 재 설정 배포가 필요하다. keystone_identity_providers 변수 아래로 dev24 oidc_keycloak 이름의 IdP(Identity Providers)와 keystone_identity_mappings으로 IdP Mapping 이 되는 설정이 들어간다.
각각의 설정에 따라 리스트로 해당 설정의 파일 등을 위에서 설정한 것과 같이 진행한다.
앞서 , KeyCloak에서 Implicit flow를 설정 해제 하였기 때문에, keystone_federation_oidc_response_type를 code로 한다. 기본 설정은 id_token으로 되어 있다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# tree /home/kolla/sso/
/home/kolla/sso/
└── odic
├── attribute_mapping
│ └── dev24deploy.cyuucloud.xyz.keystone_identity_mapping.json
└── metadata
└── dev24deploy.cyuucloud.xyz
├── dev24deploy.cyuucloud.xyz%3A8443%2Frealms%2Fmaster.client
└── dev24deploy.cyuucloud.xyz%3A8443%2Frealms%2Fmaster.provider
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# cat /etc/kolla/globals.yml
//...
keystone_identity_providers:
- name: "dev24oidc"
openstack_domain: "Default"
protocol: "openid"
identifier: "https://dev24deploy.cyuucloud.xyz:8443/realms/master"
public_name: "dev24oidc"
attribute_mapping: "dev24oidc_mappingId1"
metadata_folder: "/home/kolla/sso/odic/metadata/dev24deploy.cyuucloud.xyz"
# We also need to configure the attribute mapping that is used by IdPs.
# The configuration of attribute mappings is a list of objects, where each
# object must have a 'name' (that mapps to the 'attribute_mapping' to the IdP
# object in the IdPs set), and the 'file' with a full qualified path to a mapping file.
keystone_identity_mappings:
- name: "dev24oidc_mappingId1"
file: "/home/kolla/sso/odic/attribute_mapping/dev24deploy.cyuucloud.xyz.keystone_identity_mapping.json"
keystone_federation_oidc_response_type: "code"
keystone_federation_oidc_additional_options:
OIDCTokenBindingPolicy: disabled변경된 사항을 kolla-ansible 명령으로 reconfigure 해준다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# kolla-ansible -i /etc/kolla/multinode reconfigure --tag horizon,keystone -e ansible_python_interpreter=/usr/bin/python3
//...
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# openstack mapping list
+----------------------+----------------+
| ID | schema_version |
+----------------------+----------------+
| dev24oidc_mappingId1 | |
+----------------------+----------------+
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# openstack identity provider list
+-----------+---------+-----------+-------------+
| ID | Enabled | Domain ID | Description |
+-----------+---------+-----------+-------------+
| dev24oidc | True | default | dev24oidc |
+-----------+---------+-----------+-------------+Horizon을 통하여 로그인을 하기 전, 현 User와 Project 상태를 확인한다. 별도의 User 나 Project는 없는 상태이다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:/etc/kolla-docker/sso/oidc/attribute_mapping# openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| be38dd3e6a974ba2ba457bfaf68a516d | service |
| d399bb8349844656a743d73fae3361e1 | admin |
+----------------------------------+---------+
(cy-deploy-env) root@cyyoon-c1-deploy-010:/etc/kolla-docker/sso/oidc/attribute_mapping# openstack user list
+----------------------------------+-------------------+
| ID | Name |
+----------------------------------+-------------------+
| 294a695ed2854962b3337a54ebabdf18 | admin |
| 4b03def9c1b7408f8a203394a7bd9280 | glance |
| d712ab53367a4dac989cc2500ed6acaf | cinder |
| 8a64036c94ec4760b769e6c0aec3ee52 | placement |
| cc8c6ff3648e46cd9cd3a694e09cdc10 | nova |
| 6839dca1d425485ab83c9001ad235a72 | neutron |
| a1d9b3b62e5044978cf45ff306715c63 | heat |
| 6c767a6bebd24c238d5590d32335c7fc | heat_domain_admin |
| 79a82c3e33bf4764ab3a05ca790dd19c | skyline |
+----------------------------------+-------------------+Hoziron으로 로그인을 하게 되면, 인증 사용에 Keystone 외 추가된 IdP 정보를 확인할 수 있다.
IdP를 선택하게 되면, KeyCloak의 로그인 정보를 확인할 수 있다. 앞서 테스트를 위하여 생성한 계정을 정보로 로그인해준다.
로그인이 완료되면, 처음 로그인 하는 계정으로 인식하여 앞에서 설정한 Mapping 정보 기반으로 Prject와 User를 생성하고, 생성된 Project로 자동 Redirect 된다.
다시 CLI로 Admin 환경변수를 이용해서 전체 User와 Prject List에서 추가된 계정과 프로젝트를 확인할 수 있다.
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# openstack user list
+------------------------------------------------------------------+-------------------+
| ID | Name |
+------------------------------------------------------------------+-------------------+
| d25b07dbe8cd2f0574cf534333c98cd0a053926f869149924a63e8fa040ad7c7 | cyyoon-test-001 |
| 294a695ed2854962b3337a54ebabdf18 | admin |
| 4b03def9c1b7408f8a203394a7bd9280 | glance |
| d712ab53367a4dac989cc2500ed6acaf | cinder |
| 8a64036c94ec4760b769e6c0aec3ee52 | placement |
| cc8c6ff3648e46cd9cd3a694e09cdc10 | nova |
| 6839dca1d425485ab83c9001ad235a72 | neutron |
| a1d9b3b62e5044978cf45ff306715c63 | heat |
| 6c767a6bebd24c238d5590d32335c7fc | heat_domain_admin |
| 79a82c3e33bf4764ab3a05ca790dd19c | skyline |
+------------------------------------------------------------------+-------------------+
(cy-deploy-env) root@cyyoon-c1-deploy-010:~# openstack project list
+----------------------------------+-------------------------+
| ID | Name |
+----------------------------------+-------------------------+
| a7affce931bc4781b83826b3e6e567bf | project-cyyoon-test-001 |
| be38dd3e6a974ba2ba457bfaf68a516d | service |
| d399bb8349844656a743d73fae3361e1 | admin |
+----------------------------------+-------------------------+
Openstack / Keycloack Flow
이제 위 로그인 과정을 Flow로 확인을 해보겠다. Flow는 아래 이미지와 같다. 최종 목적은 Horizon을 통하여 Openstack 대시보드에 접근하는 과정을 도식화한 것이다.
여기서 Keystone에서 API 사용에 Apache에 mod_auth_openidc (https://github.com/OpenIDC/mod_auth_openidc) 이름의 해당 모듈을 통한 OpenID Connector 인증이 수행되며 위 Flow에 나와 있는 순서로 하나씩 보면 아래와 같다.
(1) Horizon에서 IdP를 선택하고, 등록된 IdP 정보로 Horizon 이 Redirect 시킨다.
(2)~(3) IdP로 로그인하게 되면, IdP는 Authorizatiom Code를 받은 뒤, Authorizatiom Code를 수신하게 되며, Keystone으로 Rdirect 하도록 한다.
(4) 이제 다시, IdP로부터 Redirect 되어 Keystone으로 Openstack Token을 생성하도록 요청을 하게 된다.
(5~6)
앞에서 전달받는 Authorizatiom Code를 Keystone이 KeyCloak으로 전달한다.
여기서 Keystone 은 Authorizatiom Code를 KeyClock에게 전달 Access Key를 받는 OAuth2와 다르게 OIDC에서는 Id Token를 응답 반게 된다. 앞서 이야기한 것처럼 인증과 인가가 분리된 역할로 OAuth2 같은 경우 인가되었음을 Access Key를 통하여 받으면 되는 것이지만 , 인증되었음을 알고 그 인증된 정보를 JSON Web Token (JWT) 형식으로, 사용자의 인증 정보를 담고 있으며, 클라이언트가 사용자의 신원을 확인할 수 있게 해 주기 때문에 ID Token으로 응답한다.
이러한 정보는 KeyCloak에서 Event를 활성화했다면 확인할 수 있다.
(7) 인증이 완료되면 Keystone 은 Browser에 Keystone WebSSO redirect 페이지를 200으로 전달하는데 해당 페이지는 단순 HTML 파일로 Openstack Token 정보가 추가되어, 바로 Redirect 되는 구조로 되어 있다. 즉, Header에 별도로 토큰을 주는 것이 아닌 접근 하면 토큰이 있는 정적 파일을 통하여 로그인을 할 수 있도록 해주는 것이다.
Summary
이제 모든 Application 을 기업이나 조직에서 사용 할때 SSO 는 필수 적인 요건이 되고 있다. Openstack 에서 SAML 이다 Keystone To Keystone 과 같은 Federation 은 많이 있었지만 OpenID Connector 에 대한 Reference 가 없었는데 2023년 Open Infra에서 발표 한 뒤 https://www.youtube.com/watch?v=byobgGTiuK0) 많이 생길 것 같다는 생각이 든다. 이전에도 시도 했으나 불안정 하고 트러블 슈팅 하기 힘들다고 생각 했는데 많이 안정화 된거 같다. 설정도 사실 몇줄 안되는 설정이지만 , Oauth2 나 OpenID Connector 의 Flow 를 정확하게 이해 하고 적용 해야 할 것이다.
Reference
- OIDC를 Openstack에서 사용한다면 반드시 봐야 할 영상: https://www.youtube.com/watch?v=byobgGTiuK0
- Openstack 공식 페이지: https://docs.openstack.org/kolla-ansible/latest/contributor/setup-identity-provider.html#attribute-mapping
- Openstack 공식 페이지: https://docs.openstack.org/keystone/latest//admin/federation/configure_federation.html
- Keystone Federation 설명 : http://www.gazlene.net/demystifying-keystone-federation.html
- OIDC 설명 : https://devocean.sk.com/blog/techBoardDetail.do?ID=165131
- https://docs.walt.id/v/idpkit/concepts/oidc-recap
'Openstack' 카테고리의 다른 글
| Podman 기반 Opensatck 구성 [1] (Kolla-ansible Bobcat/Cephadm Ceph) (0) | 2024.02.17 |
|---|---|
| openstack instance and kubernetes pod communication using ovs (0) | 2020.08.09 |
| openstack helm을 이용한 kubernetes환경에서 openstack 배포 (0) | 2020.08.02 |
| DVR packet flow(FIP:North-south) (0) | 2018.12.01 |
| Ansible Cloud(openstack) 모듈을 이용한 볼륨/인스턴스 생성 (0) | 2018.10.21 |
